* LVM2/tools vgchange.c
From: zkabelac @ 2011-10-22 16:47 UTC (permalink / raw)
To: lvm-devel
CVSROOT: /cvs/lvm2
Module name: LVM2
Changes by: zkabelac at sourceware.org 2011-10-22 16:47:23
Modified files:
tools : vgchange.c
Log message:
Ensure thin LVs take an exclusive activation
Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/tools/vgchange.c.diff?cvsroot=lvm2&r1=1.123&r2=1.124
--- LVM2/tools/vgchange.c 2011/09/14 18:20:04 1.123
+++ LVM2/tools/vgchange.c 2011/10/22 16:47:23 1.124
@@ -145,7 +145,10 @@
stack;
continue;
}
- } else if (lv_is_origin(lv) || (activate == CHANGE_AE)) {
+ } else if (lv_is_origin(lv) ||
+ lv_is_thin_pool(lv) ||
+ lv_is_thin_volume(lv) ||
+ (activate == CHANGE_AE)) {
if (!activate_lv_excl(cmd, lv)) {
stack;
continue;
^ permalink raw reply
* LVM2/lib/metadata lv_manip.c
From: zkabelac @ 2011-10-22 16:46 UTC (permalink / raw)
To: lvm-devel
CVSROOT: /cvs/lvm2
Module name: LVM2
Changes by: zkabelac at sourceware.org 2011-10-22 16:46:34
Modified files:
lib/metadata : lv_manip.c
Log message:
Remove extra empty check
dm_list_splice handles empty list itself, no need to duplicate code.
Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/lib/metadata/lv_manip.c.diff?cvsroot=lvm2&r1=1.301&r2=1.302
--- LVM2/lib/metadata/lv_manip.c 2011/10/22 16:42:11 1.301
+++ LVM2/lib/metadata/lv_manip.c 2011/10/22 16:46:34 1.302
@@ -4139,8 +4139,7 @@
lv->minor);
}
- if (!dm_list_empty(&lp->tags))
- dm_list_splice(&lv->tags, &lp->tags);
+ dm_list_splice(&lv->tags, &lp->tags);
lp->region_size = adjusted_mirror_region_size(vg->extent_size,
lp->extents,
^ permalink raw reply
* LVM2/lib/thin thin.c
From: zkabelac @ 2011-10-22 16:45 UTC (permalink / raw)
To: lvm-devel
CVSROOT: /cvs/lvm2
Module name: LVM2
Changes by: zkabelac at sourceware.org 2011-10-22 16:45:25
Modified files:
lib/thin : thin.c
Log message:
Consistently use metadata LV as the first in MDA
Cosmetic cleanup.
Mark LV as thin pool before calling attach_pool functions.
Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/lib/thin/thin.c.diff?cvsroot=lvm2&r1=1.24&r2=1.25
--- LVM2/lib/thin/thin.c 2011/10/21 11:38:36 1.24
+++ LVM2/lib/thin/thin.c 2011/10/22 16:45:25 1.25
@@ -92,34 +92,35 @@
const char *lv_name;
struct logical_volume *pool_data_lv, *pool_metadata_lv;
- if (!dm_config_get_str(sn, "pool", &lv_name))
- return SEG_LOG_ERROR("Pool must be a string in");
-
- if (!(pool_data_lv = find_lv(seg->lv->vg, lv_name)))
- return SEG_LOG_ERROR("Unknown pool %s in", lv_name);
-
if (!dm_config_get_str(sn, "metadata", &lv_name))
return SEG_LOG_ERROR("Metadata must be a string in");
if (!(pool_metadata_lv = find_lv(seg->lv->vg, lv_name)))
return SEG_LOG_ERROR("Unknown metadata %s in", lv_name);
- if (!attach_pool_data_lv(seg, pool_data_lv))
- return_0;
+ if (!dm_config_get_str(sn, "pool", &lv_name))
+ return SEG_LOG_ERROR("Pool must be a string in");
+ if (!(pool_data_lv = find_lv(seg->lv->vg, lv_name)))
+ return SEG_LOG_ERROR("Unknown pool %s in", lv_name);
+
+ seg->lv->status |= THIN_POOL;
if (!attach_pool_metadata_lv(seg, pool_metadata_lv))
return_0;
+ if (!attach_pool_data_lv(seg, pool_data_lv))
+ return_0;
+
if (!dm_config_get_uint64(sn, "transaction_id", &seg->transaction_id))
return SEG_LOG_ERROR("Could not read transaction_id for");
+ if (!dm_config_get_uint32(sn, "data_block_size", &seg->data_block_size))
+ return SEG_LOG_ERROR("Could not read data_block_size");
+
if (dm_config_has_node(sn, "low_water_mark") &&
!dm_config_get_uint64(sn, "low_water_mark", &seg->low_water_mark))
return SEG_LOG_ERROR("Could not read low_water_mark");
- if (!dm_config_get_uint32(sn, "data_block_size", &seg->data_block_size))
- return SEG_LOG_ERROR("Could not read data_block_size");
-
if ((seg->data_block_size < DM_THIN_MIN_DATA_BLOCK_SIZE) ||
(seg->data_block_size > DM_THIN_MAX_DATA_BLOCK_SIZE))
return SEG_LOG_ERROR("Unsupported value %u for data_block_size",
@@ -129,8 +130,6 @@
!dm_config_get_uint32(sn, "zero_new_blocks", &seg->zero_new_blocks))
return SEG_LOG_ERROR("Could not read zero_new_blocks for");
- seg->lv->status |= THIN_POOL;
-
/* Read messages */
for (; sn; sn = sn->sib)
if (!(sn->v) && !_thin_pool_add_message(seg, sn->key, sn->child))
@@ -152,9 +151,10 @@
unsigned cnt = 0;
const struct lv_thin_message *tmsg;
- outf(f, "pool = \"%s\"", seg_lv(seg, 0)->name);
outf(f, "metadata = \"%s\"", seg->pool_metadata_lv->name);
+ outf(f, "pool = \"%s\"", seg_lv(seg, 0)->name);
outf(f, "transaction_id = %" PRIu64, seg->transaction_id);
+// FIXME maybe switch to use chunksize (as with snapshot ??)
outf(f, "data_block_size = %u", seg->data_block_size);
if (seg->low_water_mark)
^ permalink raw reply
* LVM2/lib/metadata metadata.h thin_manip.c
From: zkabelac @ 2011-10-22 16:44 UTC (permalink / raw)
To: lvm-devel
CVSROOT: /cvs/lvm2
Module name: LVM2
Changes by: zkabelac at sourceware.org 2011-10-22 16:44:23
Modified files:
lib/metadata : metadata.h thin_manip.c
Log message:
Recoded way to insert thin pool into vg
Code in _lv_insert_empty_sublvs was not able to provide proper
initialization order for thin pool LV.
New function extend_pool() first adds metadata segment to pool LV which
is still visible. Such LV is activate and cleared.
Then new meta LV is created and metadata segments are moved there.
Now the preallocated pool data segment is attached to the pool LV
and layer _tpool is created. Finaly segment is marked as thin_pool.
Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/lib/metadata/metadata.h.diff?cvsroot=lvm2&r1=1.260&r2=1.261
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/lib/metadata/thin_manip.c.diff?cvsroot=lvm2&r1=1.12&r2=1.13
--- LVM2/lib/metadata/metadata.h 2011/10/22 16:42:11 1.260
+++ LVM2/lib/metadata/metadata.h 2011/10/22 16:44:23 1.261
@@ -69,6 +69,7 @@
struct dm_config_tree;
struct metadata_area;
+struct alloc_handle;
/* Per-format per-metadata area operations */
struct metadata_area_ops {
@@ -461,6 +462,8 @@
struct logical_volume *lv, uint32_t delete_id,
int read_only);
int detach_pool_messages(struct lv_segment *seg);
+int extend_pool(struct logical_volume *lv, const struct segment_type *segtype,
+ struct alloc_handle *ah);
/*
* Begin skeleton for external LVM library
--- LVM2/lib/metadata/thin_manip.c 2011/10/19 16:42:14 1.12
+++ LVM2/lib/metadata/thin_manip.c 2011/10/22 16:44:23 1.13
@@ -13,6 +13,8 @@
*/
#include "lib.h"
+#include "activate.h"
+#include "locking.h"
#include "metadata.h"
#include "segtype.h"
#include "lv_alloc.h"
@@ -216,3 +218,96 @@
return max_id;
}
+
+int extend_pool(struct logical_volume *pool_lv, const struct segment_type *segtype,
+ struct alloc_handle *ah)
+{
+ const struct segment_type *striped;
+ struct logical_volume *meta_lv, *data_lv;
+ struct lv_segment *seg;
+ const size_t len = strlen(pool_lv->name) + 16;
+ char name[len];
+
+ if (lv_is_thin_pool(pool_lv)) {
+ log_error("Resize of pool %s not yet implemented.", pool_lv->name);
+ return 0;
+ }
+
+ /* LV is not yet a pool, so it's extension from lvcreate */
+ if (!(striped = get_segtype_from_string(pool_lv->vg->cmd, "striped")))
+ return_0;
+
+ if (activation() && segtype->ops->target_present &&
+ !segtype->ops->target_present(pool_lv->vg->cmd, NULL, NULL)) {
+ log_error("%s: Required device-mapper target(s) not "
+ "detected in your kernel.", segtype->name);
+ return 0;
+ }
+
+ /* Metadata segment */
+ if (!lv_add_segment(ah, 1, 1, pool_lv, striped, 1, 0, 0))
+ return_0;
+
+ if (activation()) {
+ if (!vg_write(pool_lv->vg) || !vg_commit(pool_lv->vg))
+ return_0;
+
+ /*
+ * If killed here, only the VISIBLE striped pool LV is left
+ * and user could easily remove it.
+ *
+ * FIXME: implement lazy clearing when activation is disabled
+ */
+
+ // FIXME: activate_lv_local_excl is actually wanted here
+ if (!activate_lv_local(pool_lv->vg->cmd, pool_lv) ||
+ // FIXME: maybe -zero n should allow to recreate same thin pool
+ // and different option should be used for zero_new_blocks
+ /* Clear 4KB of metadata device for new thin-pool. */
+ !set_lv(pool_lv->vg->cmd, pool_lv, UINT64_C(0), 0)) {
+ log_error("Aborting. Failed to wipe pool metadata %s.",
+ pool_lv->name);
+ return 0;
+ }
+
+ if (!deactivate_lv_local(pool_lv->vg->cmd, pool_lv)) {
+ log_error("Aborting. Could not deactivate pool metadata %s.",
+ pool_lv->name);
+ return 0;
+ }
+ } else {
+ log_error("Pool %s created without initilization.", pool_lv->name);
+ }
+
+ if (dm_snprintf(name, len, "%s_tmeta", pool_lv->name) < 0)
+ return_0;
+
+ if (!(meta_lv = lv_create_empty(name, NULL, LVM_READ | LVM_WRITE,
+ ALLOC_INHERIT, pool_lv->vg)))
+ return_0;
+
+ if (!move_lv_segments(meta_lv, pool_lv, 0, 0))
+ return_0;
+
+ /* Pool data segment */
+ if (!lv_add_segment(ah, 0, 1, pool_lv, striped, 1, 0, 0))
+ return_0;
+
+ if (!(data_lv = insert_layer_for_lv(pool_lv->vg->cmd, pool_lv,
+ pool_lv->status, "_tpool")))
+ return_0;
+
+ seg = first_seg(pool_lv);
+ seg->segtype = segtype; /* Set as thin_pool segment */
+ seg->lv->status |= THIN_POOL;
+
+ if (!attach_pool_metadata_lv(seg, meta_lv))
+ return_0;
+
+ /* Drop reference as attach_pool_data_lv() takes it again */
+ remove_seg_from_segs_using_this_lv(data_lv, seg);
+ if (!attach_pool_data_lv(seg, data_lv))
+ return_0;
+
+ return 1;
+}
^ permalink raw reply
* Re: Kernel hard LOCKUP with v3.0.7
From: Stefan Priebe @ 2011-10-22 16:44 UTC (permalink / raw)
To: Greg KH; +Cc: LKML, Stable Tree
In-Reply-To: <20111021200257.GA31198@suse.de>
Hi,
> Can you run 'git bisect' to try to find the problem patch? Oh, there is
> one bugfix that I know of, bcd5cff7216f9b2de0a148cc355eac199dc6f1cf in
> Linus's tree, can you try that to see if it solves the problem for you?
this seems to fix it. Perhaps you should release v3.0.8 as the stable
tree isn't stable right now? I mean this bug seems to be triggered on
every SMP machine.
Stefan
^ permalink raw reply
* LVM2 ./WHATS_NEW lib/metadata/lv_manip.c lib/m ...
From: zkabelac @ 2011-10-22 16:42 UTC (permalink / raw)
To: lvm-devel
CVSROOT: /cvs/lvm2
Module name: LVM2
Changes by: zkabelac at sourceware.org 2011-10-22 16:42:11
Modified files:
. : WHATS_NEW
lib/metadata : lv_manip.c metadata.h
Log message:
Make move_lv_segment non-static
This function could be useful for other _manip source files.
Use dm_list manipulation function for provided functionality,
which make the code more readable and avoid touching list
internal details here.
Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/WHATS_NEW.diff?cvsroot=lvm2&r1=1.2166&r2=1.2167
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/lib/metadata/lv_manip.c.diff?cvsroot=lvm2&r1=1.300&r2=1.301
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/lib/metadata/metadata.h.diff?cvsroot=lvm2&r1=1.259&r2=1.260
--- LVM2/WHATS_NEW 2011/10/21 15:49:45 1.2166
+++ LVM2/WHATS_NEW 2011/10/22 16:42:10 1.2167
@@ -1,5 +1,6 @@
Version 2.02.89 -
==================================
+ Make move_lv_segment non-static function and use dm_list function.
Pass exclusive LV locks to all nodes in the cluster.
Improve lvcreate man documentation of the chunksize option.
Improve man page style for lvcreate.
--- LVM2/lib/metadata/lv_manip.c 2011/10/21 11:38:35 1.300
+++ LVM2/lib/metadata/lv_manip.c 2011/10/22 16:42:11 1.301
@@ -3446,23 +3446,20 @@
return 1;
}
-static int _move_lv_segments(struct logical_volume *lv_to,
- struct logical_volume *lv_from,
- uint64_t set_status, uint64_t reset_status)
+int move_lv_segments(struct logical_volume *lv_to,
+ struct logical_volume *lv_from,
+ uint64_t set_status, uint64_t reset_status)
{
struct lv_segment *seg;
- dm_list_iterate_items(seg, &lv_to->segments) {
+ dm_list_iterate_items(seg, &lv_to->segments)
if (seg->origin) {
- log_error("Can't move snapshot segment");
+ log_error("Can't move snapshot segment.");
return 0;
}
- }
- if (!dm_list_empty(&lv_from->segments))
- lv_to->segments = lv_from->segments;
- lv_to->segments.n->p = &lv_to->segments;
- lv_to->segments.p->n = &lv_to->segments;
+ dm_list_init(&lv_to->segments);
+ dm_list_splice(&lv_to->segments, &lv_from->segments);
dm_list_iterate_items(seg, &lv_to->segments) {
seg->lv = lv_to;
@@ -3470,8 +3467,6 @@
seg->status |= set_status;
}
- dm_list_init(&lv_from->segments);
-
lv_to->le_count = lv_from->le_count;
lv_to->size = lv_from->size;
@@ -3512,7 +3507,7 @@
if (!lv_empty(parent))
return_0;
- if (!_move_lv_segments(parent, layer_lv, 0, 0))
+ if (!move_lv_segments(parent, layer_lv, 0, 0))
return_0;
/* Replace the empty layer with error segment */
@@ -3602,7 +3597,7 @@
log_very_verbose("Inserting layer %s for %s",
layer_lv->name, lv_where->name);
- if (!_move_lv_segments(layer_lv, lv_where, 0, 0))
+ if (!move_lv_segments(layer_lv, lv_where, 0, 0))
return_NULL;
if (!(segtype = get_segtype_from_string(cmd, "striped")))
--- LVM2/lib/metadata/metadata.h 2011/10/19 16:39:09 1.259
+++ LVM2/lib/metadata/metadata.h 2011/10/22 16:42:11 1.260
@@ -420,6 +420,9 @@
int (*fn)(struct cmd_context *cmd,
struct logical_volume *lv, void *data),
void *data);
+int move_lv_segments(struct logical_volume *lv_to,
+ struct logical_volume *lv_from,
+ uint64_t set_status, uint64_t reset_status);
/*
* Calculate readahead from underlying PV devices
^ permalink raw reply
* [PATCH] spi/pl022: Enable clock in probe an use runtime_idle
From: Linus Walleij @ 2011-10-22 16:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319206124-17549-1-git-send-email-ulf.hansson@stericsson.com>
On Fri, Oct 21, 2011 at 4:08 PM, Ulf Hansson <ulf.hansson@stericsson.com> wrote:
> Since we are always runtime resumed when leaving probe
> the clock must be enabled. To accomplish that we are able
> to be runtime suspended after probe in the case when no
> request is going to be recieved, a runtime_idle function
> has been implemented.
>
> Change-Id: I6cb86f2cad30ecaab16f512daf4674b039b18213
> Signed-off-by: Ulf Hansson <ulf.hansson@stericsson.com>
> Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/34447
Skip the gerrit weirdo stuff.
Notice that this patch cannot be merged until Russell's
AMBA PM patches are merged, so put this in Russell's
patch tracker so he can put it on his AMBA PM branch.
But looks correct.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] spi/pl022: Enable clock in probe an use runtime_idle
From: Linus Walleij @ 2011-10-22 16:41 UTC (permalink / raw)
To: Ulf Hansson
Cc: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, Lee Jones,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Russell King - ARM Linux
In-Reply-To: <1319206124-17549-1-git-send-email-ulf.hansson-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org>
On Fri, Oct 21, 2011 at 4:08 PM, Ulf Hansson <ulf.hansson-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org> wrote:
> Since we are always runtime resumed when leaving probe
> the clock must be enabled. To accomplish that we are able
> to be runtime suspended after probe in the case when no
> request is going to be recieved, a runtime_idle function
> has been implemented.
>
> Change-Id: I6cb86f2cad30ecaab16f512daf4674b039b18213
> Signed-off-by: Ulf Hansson <ulf.hansson-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org>
> Reviewed-on: http://gerrit.lud.stericsson.com/gerrit/34447
Skip the gerrit weirdo stuff.
Notice that this patch cannot be merged until Russell's
AMBA PM patches are merged, so put this in Russell's
patch tracker so he can put it on his AMBA PM branch.
But looks correct.
Acked-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Yours,
Linus Walleij
------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
^ permalink raw reply
* [U-Boot] A bit about board.c, board.c
From: Simon Glass @ 2011-10-22 16:40 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4EA26DFD.2000102@aribaud.net>
Hi Albert,
On Sat, Oct 22, 2011 at 12:17 AM, Albert ARIBAUD
<albert.u.boot@aribaud.net> wrote:
> Le 22/10/2011 07:11, Simon Glass a ?crit :
>>
>> Hi,
>>
>> Each architecture has its own board.c but they are mostly quite similar.
>>
>> New features such as fdt, boot timing, trace, profiling, etc. must be
>> done separately for each arch, even if there are no
>> architecture-specific bits.
>>
>> What would you say to adding something like lib/board.c which is a
>> simplified cleaned-up copy of one of the existing board.c files, and a
>> CONFIG_ARCH_GENERIC_BOARD option to select that in preference to the
>> architecture-specific one. Then perhaps people could try it out and we
>> could slowly move to it over time...
>
> I'd say anything that factorizes ARM code is a good thing. :)
>
> However I'm not in favor of a CONFIG option that would force the board code
> to provide some functions just in odrer to override one, not if weak
My suggestion was:
CONFIG_ARCH_GENERIC_BOARD - you get lib/board.c
not CONFIG_ARCH_GENERIC_BOARD - you get arch/xxx/lib/board.c
> definitions can do a finer job. I am looking into that already for cache
> management function specialization, and it seems like there is the same kind
> of possibility here, with lib functions defined weak and the board code
> overriding the ones it deems necessary to.
ok. Just one little point. Weak symbols are the punishment our C++
overlords gave us for not having to understand what code is executed
when we instantiate a C++ subclass. It is nice to know what code is
being linked in and avoid having to disassemble to find out. I think
using weak symbols to avoid a OBJS-$(CONFIG_ARCH_GENERIC_BOARD) in a
couple of Makefiles risks going too far.
Regards,
Simon
Regards,
Simon
Regards,
Simon
>
> I will look into it a bit more this morning.
>
> Amicalement,
> --
> Albert.
>
^ permalink raw reply
* tag process's future sockets for iptables rules?
From: p. awa @ 2011-10-22 16:34 UTC (permalink / raw)
To: netfilter
i used to do redirection and filtering based on the uid of a packet's
local socket. the point was to transparently proxy an arbitrary process's
outbound tcp connections through tor[1]. it had a nice enough interface:
$ sudo torified-user wget http://example.com/
then i switched to filtering based on gid instead of uid: having only
the gid of regular files created by a process screwed with was less
intrusive. but it is all still a hack that becomes unwieldy when you
need more complex filtering rules.
so i wonder if netfilter provides a facility that would allow a process
to specify tags that are then added onto all sockets/connections/packets
this process and its children create in the future, and to filter based
upon those tags. something like:
| netfilter_add_tag("public-addresses-proxied-via-tor");
| netfilter_add_tag("internal-addresses-directly");
| netfilter_remove_tag("proxy-dns");
| execlp("wget", ...);
plus corresponding iptables rules:
# iptables ... --with-tag public-addresses-proxied-via-tor \
--with-tag internal-addresses-directly \
--without-tag proxy-dns ...
is there such a thing? of course it wouldn't have to be this interface
exactly, e.g. instead of strings the tags could be bits like connmark's
value/mask. there wouldn't be by any chance a way to to set a "default
connmark value" from inside a process, would there?
please note that i'm only asking about this tagging facility, and not
about the proxying use case above (which is merely a simplified example).
cheers
[1] https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TransparentProxy
^ permalink raw reply
* [Adeos-main] Pull request for ipipe-2.6.38-arm
From: Gilles Chanteperdrix @ 2011-10-22 16:34 UTC (permalink / raw)
To: Adeos
The following changes since commit 7e123a255731dd6e09eb583402b50fc59414cfbd:
ipipe noarch: add const attribute to irq_get_irq_data (2011-10-10 20:37:36 +0200)
are available in the git repository at:
git://git.xenomai.org/ipipe-gch.git for-ipipe-2.6.38-arm
Gilles Chanteperdrix (16):
FCSE: pid life cycle
FCSE: Conversions between VA and MVA
FCSE: Address-space limits
FCSE: Make the shared mappings uncacheable
FCSE: do not flush cache during context switch
"Best-effort" FCSE: choose whether to flush cache at run-time
"Best-effort" FCSE: Allow PID re-use
"Best-effort" FCSE: Handle mappings above 32 MB
"Best effort" FCSE: Reserve address-space for stack
"Best-effort" FCSE: Handle shared mappings
"Best effort" FCSE: Dynamic FCSE pid switching
FCSE: add Makefile and compilation option
Merge branch 'fcse-2.6.38' into for-ipipe-2.6.38-arm2
omap2+: get sched_clock working without CONFIG_OMAP_32K_TIMER
omap4/smp_twd: get frequency from SoC clock rate
forward port, rebase on 2.6.38-noarch, adeos-ipipe-2.6.38.8-arm-1.18-03
arch/arm/Kconfig | 13 +
arch/arm/boot/compressed/head.S | 9 +
arch/arm/common/gic.c | 140 +++--
arch/arm/common/it8152.c | 7 +-
arch/arm/common/timer-sp.c | 80 +++-
arch/arm/include/asm/assembler.h | 24 +
arch/arm/include/asm/atomic.h | 16 +-
arch/arm/include/asm/bitops.h | 24 +-
arch/arm/include/asm/cacheflush.h | 75 ++-
arch/arm/include/asm/cpu-multi32.h | 10 +
arch/arm/include/asm/cpu-single.h | 5 +
arch/arm/include/asm/entry-macro-multi.S | 12 +
arch/arm/include/asm/fcse.h | 181 ++++++
arch/arm/include/asm/hardware/timer-sp.h | 2 +-
arch/arm/include/asm/ipipe.h | 340 ++++++++++
arch/arm/include/asm/ipipe_base.h | 150 +++++
arch/arm/include/asm/irqflags.h | 244 +++++---
arch/arm/include/asm/memory.h | 5 +
arch/arm/include/asm/mmu.h | 15 +-
arch/arm/include/asm/mmu_context.h | 128 ++++-
arch/arm/include/asm/percpu.h | 4 +
arch/arm/include/asm/pgtable.h | 82 ++-
arch/arm/include/asm/proc-fns.h | 13 +-
arch/arm/include/asm/processor.h | 5 +
arch/arm/include/asm/resource.h | 10 +
arch/arm/include/asm/smp_twd.h | 60 ++-
arch/arm/include/asm/system.h | 17 +-
arch/arm/include/asm/thread_info.h | 12 +
arch/arm/include/asm/tlbflush.h | 14 +-
arch/arm/kernel/Makefile | 4 +-
arch/arm/kernel/entry-armv.S | 153 +++++-
arch/arm/kernel/entry-common.S | 64 ++-
arch/arm/kernel/entry-header.S | 8 +-
arch/arm/kernel/ipipe.c | 675 ++++++++++++++++++++
arch/arm/kernel/ipipe_tsc.c | 136 ++++
arch/arm/kernel/ipipe_tsc_asm.S | 205 ++++++
arch/arm/kernel/irq.c | 2 +
arch/arm/kernel/process.c | 30 +-
arch/arm/kernel/ptrace.c | 4 +
arch/arm/kernel/smp.c | 83 +++-
arch/arm/kernel/smp_twd.c | 176 +++++-
arch/arm/kernel/traps.c | 10 +
arch/arm/mach-at91/Kconfig | 13 +
arch/arm/mach-at91/Makefile | 11 +
arch/arm/mach-at91/at91_ipipe_time.c | 316 +++++++++
arch/arm/mach-at91/at91rm9200.c | 44 ++
arch/arm/mach-at91/at91sam9260.c | 44 ++
arch/arm/mach-at91/at91sam9261.c | 44 ++
arch/arm/mach-at91/at91sam9263.c | 44 ++
arch/arm/mach-at91/at91sam9rl.c | 44 ++
arch/arm/mach-at91/gpio.c | 116 ++++-
arch/arm/mach-at91/include/mach/hardware.h | 19 +
arch/arm/mach-at91/include/mach/irqs.h | 2 +
arch/arm/mach-at91/include/mach/timex.h | 2 +-
arch/arm/mach-at91/irq.c | 3 +
arch/arm/mach-imx/clock-imx1.c | 2 +-
arch/arm/mach-imx/clock-imx21.c | 2 +-
arch/arm/mach-imx/clock-imx27.c | 3 +-
arch/arm/mach-integrator/core.c | 1 +
.../arm/mach-integrator/include/mach/entry-macro.S | 6 +-
arch/arm/mach-integrator/include/mach/irqs.h | 1 -
arch/arm/mach-integrator/include/mach/platform.h | 6 +-
arch/arm/mach-integrator/include/mach/timex.h | 4 +-
arch/arm/mach-integrator/integrator_cp.c | 14 +-
arch/arm/mach-ixp4xx/common.c | 178 +++++-
arch/arm/mach-ixp4xx/include/mach/platform.h | 9 +-
arch/arm/mach-mx3/clock-imx31.c | 3 +-
arch/arm/mach-mx3/clock-imx35.c | 5 +-
arch/arm/mach-mx3/devices.c | 1 +
arch/arm/mach-mx3/mach-mx31_3ds.c | 1 +
arch/arm/mach-mx3/mach-mx31ads.c | 3 +-
arch/arm/mach-mx5/clock-mx51-mx53.c | 4 +-
arch/arm/mach-mxc91231/clock.c | 3 +-
arch/arm/mach-omap2/board-cm-t35.c | 2 +
arch/arm/mach-omap2/board-cm-t3517.c | 2 +
arch/arm/mach-omap2/board-devkit8000.c | 2 +
arch/arm/mach-omap2/clock44xx_data.c | 9 +
arch/arm/mach-omap2/irq.c | 89 +++-
arch/arm/mach-omap2/timer-gp.c | 121 ++++-
arch/arm/mach-omap2/timer-mpu.c | 4 +-
arch/arm/mach-pxa/irq.c | 3 +
arch/arm/mach-pxa/leds-idp.c | 1 +
arch/arm/mach-pxa/leds-lubbock.c | 1 +
arch/arm/mach-pxa/leds-mainstone.c | 1 +
arch/arm/mach-pxa/lpd270.c | 3 +-
arch/arm/mach-pxa/lubbock.c | 3 +-
arch/arm/mach-pxa/mainstone.c | 3 +-
arch/arm/mach-pxa/pcm990-baseboard.c | 3 +-
arch/arm/mach-pxa/time.c | 73 +++-
arch/arm/mach-pxa/viper.c | 3 +-
arch/arm/mach-realview/core.c | 9 +-
arch/arm/mach-realview/core.h | 1 +
arch/arm/mach-realview/realview_eb.c | 1 +
arch/arm/mach-realview/realview_pb1176.c | 1 +
arch/arm/mach-realview/realview_pb11mp.c | 1 +
arch/arm/mach-realview/realview_pba8.c | 1 +
arch/arm/mach-realview/realview_pbx.c | 1 +
arch/arm/mach-s3c2410/include/mach/irqs.h | 2 +
arch/arm/mach-s3c2440/irq.c | 7 +-
arch/arm/mach-s3c2440/s3c244x-irq.c | 10 +-
arch/arm/mach-sa1100/gpio.c | 8 +-
arch/arm/mach-sa1100/irq.c | 8 +-
arch/arm/mach-sa1100/leds-assabet.c | 1 +
arch/arm/mach-sa1100/leds-badge4.c | 1 +
arch/arm/mach-sa1100/leds-cerf.c | 1 +
arch/arm/mach-sa1100/leds-hackkit.c | 1 +
arch/arm/mach-sa1100/leds-lart.c | 1 +
arch/arm/mach-sa1100/leds-simpad.c | 1 +
arch/arm/mach-sa1100/time.c | 76 +++-
arch/arm/mach-versatile/core.c | 9 +-
arch/arm/mach-vexpress/ct-ca9x4.c | 2 +-
arch/arm/mach-vexpress/v2m.c | 2 +-
arch/arm/mm/Kconfig | 84 +++-
arch/arm/mm/Makefile | 1 +
arch/arm/mm/alignment.c | 3 +
arch/arm/mm/cache-l2x0.c | 3 +-
arch/arm/mm/context.c | 57 ++-
arch/arm/mm/copypage-v4mc.c | 2 +-
arch/arm/mm/copypage-xscale.c | 2 +-
arch/arm/mm/fault-armv.c | 33 +
arch/arm/mm/fault.c | 70 ++
arch/arm/mm/fcse.c | 466 ++++++++++++++
arch/arm/mm/flush.c | 3 +-
arch/arm/mm/ioremap.c | 1 +
arch/arm/mm/mmap.c | 37 +-
arch/arm/mm/mmu.c | 2 +-
arch/arm/mm/pgd.c | 52 ++-
arch/arm/mm/proc-arm920.S | 9 +
arch/arm/mm/proc-arm926.S | 9 +
arch/arm/mm/proc-feroceon.S | 13 +
arch/arm/mm/proc-xscale.S | 9 +
arch/arm/plat-mxc/avic.c | 4 +-
arch/arm/plat-mxc/cpu.c | 35 +-
arch/arm/plat-mxc/devices.c | 22 +
arch/arm/plat-mxc/gpio.c | 89 +++-
arch/arm/plat-mxc/include/mach/common.h | 7 +-
arch/arm/plat-mxc/include/mach/gpio.h | 5 +-
arch/arm/plat-mxc/include/mach/irqs.h | 4 +
arch/arm/plat-mxc/time.c | 97 +++-
arch/arm/plat-mxc/tzic.c | 30 +
arch/arm/plat-omap/Kconfig | 8 +-
arch/arm/plat-omap/counter_32k.c | 2 +-
arch/arm/plat-omap/dmtimer.c | 51 ++-
arch/arm/plat-omap/gpio.c | 356 ++++++++++-
arch/arm/plat-omap/include/plat/dmtimer.h | 5 +
arch/arm/plat-omap/include/plat/irqs.h | 9 +
arch/arm/plat-pxa/gpio.c | 5 +-
arch/arm/plat-s3c24xx/irq.c | 37 +-
arch/arm/plat-samsung/include/plat/gpio-core.h | 2 +-
arch/arm/plat-samsung/irq-uart.c | 8 +-
arch/arm/plat-samsung/time.c | 196 +++++--
arch/arm/vfp/entry.S | 3 +-
arch/arm/vfp/vfphw.S | 16 +-
arch/arm/vfp/vfpmodule.c | 55 ++-
drivers/mfd/twl4030-irq.c | 4 +
drivers/mfd/twl6030-irq.c | 6 +-
drivers/misc/Kconfig | 14 +-
include/asm-generic/resource.h | 8 +
include/linux/resource.h | 6 -
kernel/ipipe/core.c | 72 +-
kernel/trace/Kconfig | 1 +
161 files changed, 6160 insertions(+), 516 deletions(-)
create mode 100644 arch/arm/include/asm/fcse.h
create mode 100644 arch/arm/include/asm/ipipe.h
create mode 100644 arch/arm/include/asm/ipipe_base.h
create mode 100644 arch/arm/kernel/ipipe.c
create mode 100644 arch/arm/kernel/ipipe_tsc.c
create mode 100644 arch/arm/kernel/ipipe_tsc_asm.S
create mode 100644 arch/arm/mach-at91/at91_ipipe_time.c
create mode 100644 arch/arm/mm/fcse.c
--
Gilles.
^ permalink raw reply
* Re: [PATCH] mmc: boot partition ro lock support
From: Linus Walleij @ 2011-10-22 16:33 UTC (permalink / raw)
To: Chris Ball
Cc: Andrei Warkentin, Ulf Hansson, Per Forlin, Lee Jones,
Johan Rudholm, John Beckett, linux-mmc
In-Reply-To: <m24nz171vj.fsf@bob.laptop.org>
On Sat, Oct 22, 2011 at 12:32 PM, Chris Ball <cjb@laptop.org> wrote:
> On Fri, Oct 21 2011, Andrei Warkentin wrote:
>>
>> The permalocking brick-potential (more like paper-weight-potential) is
>> IMO unacceptably high that something like this is just accessible via
>> a sysfs attribute. This is exactly why the boot partitions were put
>> under force_ro, so that some poor sap wouldn't end up nuking the boot
>> partitions (with obvious consequences), and permalocking seems even
>> nastier.
I presume the sysfs files are there exactly to avoid bricking,
by locking partitions down from userspace. So what you're saying
is that this should be done by the kernel itself or bootloader?
[Chris]
> I agree. Does anyone have an argument for including either of these?
I see the problem with having it as sysfs files, so what is our
rationale about using that documented MMC feature? I can
think of two:
1) Use a kernel cmdline param to permalock partitions
2) Only bootloaders should do such stuff
As noticed all over ARM linux' mailing lists boot loader updates are
nasty stuff, usually it's pretty hard to alter stuff there to get what
you want. Not all boot loaders are as sophisticated cmdline parsers
as U-Boot mind you...
So what about a cmdline approach? That makes it possible
for people who are willingly recompiling and hacking their kernels
to tinker with this if they absolutely want to go in on that
partition, make it rw and change stuff.
...org have I just got all this backwards...?
Yours,
Linus Walleij
^ permalink raw reply
* [Bug 39513] sensors are inaccessible on radeon 9600xt agp
From: bugzilla-daemon @ 2011-10-22 16:32 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-39513-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=39513
--- Comment #18 from almos <aaalmosss@gmail.com> 2011-10-22 09:32:56 PDT ---
(In reply to comment #17)
> I'm running kernel 3.1rc9, asus 9600xt and the f75375 sensor is detected, yet
> the readings are obviously wrong and constant:
>
><snip>
> Is there any special configuration needed?
I'm using 3.0.1 with Alex's patch, and the readings are OK (at least the
voltages and temperatures seem correct, I have a fanless cooler). No
configuration is needed and none is possible.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* [Adeos-main] Pull request for ipipe-2.6.38-noarch
From: Gilles Chanteperdrix @ 2011-10-22 16:32 UTC (permalink / raw)
To: Adeos
The following changes since commit 641d8e87531c6367a6357335378194ea06a23701:
ipipe: Prevent unwritable pages after mprotect (2011-07-21 09:51:56 +0200)
are available in the git repository at:
git://git.xenomai.org/ipipe-gch.git for-ipipe-2.6.38-noarch
Gilles Chanteperdrix (4):
ipipe: inline irq_to_desc for non-sparse irqs
ipipe: delay printk when called on root domain with hw irqs off
ipipe noarch: allow hostrt without clockevents
ipipe noarch: add const attribute to irq_get_irq_data
include/linux/ipipe_tickdev.h | 38 +++++++++++++++++++++++---------------
include/linux/irq.h | 2 +-
include/linux/irqnr.h | 4 ++++
kernel/irq/irqdesc.c | 2 ++
kernel/printk.c | 11 +++++++----
5 files changed, 37 insertions(+), 20 deletions(-)
--
Gilles.
^ permalink raw reply
* Re: lsusd - The Linux SUSpend Daemon
From: Alan Stern @ 2011-10-22 16:31 UTC (permalink / raw)
To: NeilBrown; +Cc: John Stultz, Rafael J. Wysocki, mark gross, Linux PM list, LKML
In-Reply-To: <Pine.LNX.4.44L0.1110212125020.8657-100000@netrider.rowland.org>
On Fri, 21 Oct 2011, Alan Stern wrote:
> > Maybe we could do something with futexes...
>
> Not easily -- as far as I can tell, futexes enjoy relatively little
> support. In any case, they provide the same service as a mutex, which
> means you'd have to build a shared lock on top of them.
It occurred to me that we could create a new type of special file, one
intended to help with interprocess synchronization. It would support
locking (shared or exclusive, blocking or non-blocking) and the poll
system call -- the file would appear to be ready for reading whenever a
shared lock wouldn't block and ready for writing whenever an exclusive
lock wouldn't block. Actual reads and writes wouldn't have to do
anything, although maybe someone could suggest a use for them.
Alan Stern
^ permalink raw reply
* Re: [PATCH] jme: fix irq storm after suspend/resume
From: Mantas M. @ 2011-10-22 16:27 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev
In-Reply-To: <20111022125620.GA2256@ecki.lan>
On 22/10/11 15:56, Clemens Buchacher wrote:
> If the device is down during suspend/resume, interrupts are enabled
> without a registered interrupt handler, causing a storm of
> unhandled interrupts until the IRQ is disabled because "nobody
> cared".
>
> Instead, check that the device is up before touching it in the
> suspend/resume code.
>
> Fixes https://bugzilla.kernel.org/show_bug.cgi?id=39112
Just tested the patch, suspend/resume works well.
--
Mantas M.
^ permalink raw reply
* [U-Boot] FINAL NOTIFICATION!!!
From: Microsoft Corporations @ 2011-10-22 16:24 UTC (permalink / raw)
To: u-boot
An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://lists.denx.de/pipermail/u-boot/attachments/20111023/c936ed9e/attachment.txt
^ permalink raw reply
* usbutils 005 release
From: Greg KH @ 2011-10-22 16:23 UTC (permalink / raw)
To: linux-usb; +Cc: linux-kernel
Here's the 004 release of usbutils.
Some USB 3.0 bugfixes, and a new usb.ids file update. Nothing major.
With kernel.org file upload still not fully working, please use the
github link below to get a tarball if you need/want it.
We've switched over to using git for development now, which makes things
much easier than the old cvs tree. The tree can be found on both
kernel.org and github.com if you want to fork it and send us changes
easier:
http://git.kernel.org/?p=linux/kernel/git/gregkh/usbutils.git
http://github.com/gregkh/usbutils/tree/master
thanks,
greg k-h
-----------
Greg Kroah-Hartman (7):
usb.ids: updated version of the file
Remove the FSF address from the source files.
update usbhid-dump to release 1.2
add another Linux kernel usb id.
updated usb.ids file
lsusb-t.c: fix up some complier warnings
add lsusb.h to fix some complier warnings.
Lukáš Nykrýn (1):
Add more space to lsusb.py output
Sarah Sharp (2):
lsusb: wSpeedsSupported is 2 bytes, not one.
lsusb: bU2DevExitLat is little endian, not big endian.
^ permalink raw reply
* [PATCH] kbuild: don't use a symlink for update-po-config
From: Peter Foley @ 2011-10-22 15:19 UTC (permalink / raw)
To: Linux Kernel Mailing List, Linux Kbuild Mailing List, mmarek
This patch changes update-po-config to not create a symlink in arch/um
because this fails with make O= builds.
It also improves the V=0 output.
GEN /usr/src/lto/work/Makefile
GEN config
ln: failed to create symbolic link `arch/um/Kconfig': No such file or directory
make[3]: *** [update-po-config] Error 1
make[2]: *** [update-po-config] Error 2
make[1]: *** [sub-make] Error 2
make: *** [all] Error 2
Signed-off-by: Peter Foley <pefoley2@verizon.net>
---
scripts/kconfig/Makefile | 11 +++++------
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index 82d2eb2..1d99a08 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -74,9 +74,8 @@ localyesconfig: $(obj)/streamline_config.pl $(obj)/conf
# Create new linux.pot file
# Adjust charset to UTF-8 in .po file to accept UTF-8 in Kconfig files
-# The symlink is used to repair a deficiency in arch/um
update-po-config: $(obj)/kxgettext $(obj)/gconf.glade.h
- $(Q)echo " GEN config"
+ $(Q)echo " GEN config.pot"
$(Q)xgettext --default-domain=linux \
--add-comments --keyword=_ --keyword=N_ \
--from-code=UTF-8 \
@@ -84,16 +83,16 @@ update-po-config: $(obj)/kxgettext $(obj)/gconf.glade.h
--directory=$(srctree) --directory=$(objtree) \
--output $(obj)/config.pot
$(Q)sed -i s/CHARSET/UTF-8/ $(obj)/config.pot
- $(Q)ln -fs Kconfig.x86 arch/um/Kconfig
- $(Q)(for i in `ls $(srctree)/arch/*/Kconfig`; \
+ $(Q)(for i in `ls $(srctree)/arch/*/Kconfig` \
+ $(srctree)/arch/um/Kconfig.x86; \
do \
- echo " GEN $$i"; \
+ echo " GEN $$i"; \
$(obj)/kxgettext $$i \
>> $(obj)/config.pot; \
done )
+ $(Q)echo " GEN linux.pot"
$(Q)msguniq --sort-by-file --to-code=UTF-8 $(obj)/config.pot \
--output $(obj)/linux.pot
- $(Q)rm -f $(srctree)/arch/um/Kconfig
$(Q)rm -f $(obj)/config.pot
PHONY += allnoconfig allyesconfig allmodconfig alldefconfig randconfig
--
1.7.7
^ permalink raw reply related
* Re: [bug] usb_hcd_irq, irq nobody cared & threadirqs
From: Alan Stern @ 2011-10-22 16:23 UTC (permalink / raw)
To: kanyck, Thomas Gleixner; +Cc: Kernel development list, USB list
In-Reply-To: <loom.20111022T124933-767@post.gmane.org>
This problem does not seem to be particularly related to USB. It
appears to be a bug in the threaded IRQ subsystem.
I don't know what I can do other than forward the message to people who
might know more about it.
Alan Stern
On Sat, 22 Oct 2011, kanyck wrote:
> Hello Alan and everybody,
>
> I apparently have the same problem but can't report it because the kernel.org
> is still not fully up. So I apologize if I've put my report in a wrong place...
>
> I experienced very high iowait level during intensive disk I/O (up to 87%
> per CPU) on all the kernels I tried (2.6.32 and Debian backports' 2.6.38,
> 2.6.39) running on ASUS E35M1-M PRO (AMD e-350) platform
>
> So I installed AVLinux's 3.0.3 kernel:
> Linux version 3.0.3-avl-3-pae (trulan@avlinux) (gcc version 4.6.1 (Debian
> 4.6.1-4) ) #1 SMP PREEMPT Thu Aug 18 07:18:19 EDT 2011
>
> It worked much better but after a couple of hours my ethernet stops working and
> I see the following in my syslog:
>
> Oct 16 21:31:43 localhost kernel: [14328.121907] irq 18: nobody cared (try
> booting with the "irqpoll" option)
> Oct 16 21:31:43 localhost kernel: [14328.125161] Pid: 658, comm:
> irq/18-ohci_hcd Not tainted 3.0.3-avl-3-pae #1
> Oct 16 21:31:43 localhost kernel: [14328.128863] Call Trace:
> Oct 16 21:31:43 localhost kernel: [14328.132512] [<c1068fab>] ?
> __report_bad_irq+0x1c/0x8d
> Oct 16 21:31:43 localhost kernel: [14328.136168] [<c10692c3>] ?
> note_interrupt+0x11a/0x187
> Oct 16 21:31:43 localhost kernel: [14328.139790] [<c10685df>] ?
> irq_thread+0xbf/0x15c
> Oct 16 21:31:43 localhost kernel: [14328.143373] [<c106869f>] ?
> irq_thread_fn+0x23/0x23
> Oct 16 21:31:43 localhost kernel: [14328.146900] [<c1022289>] ?
> complete+0x28/0x36
> Oct 16 21:31:43 localhost kernel: [14328.150385] [<c1068520>] ?
> irq_finalize_oneshot+0x9d/0x9d
> Oct 16 21:31:43 localhost kernel: [14328.153854] [<c1040587>] ?
> kthread+0x63/0x68
> Oct 16 21:31:43 localhost kernel: [14328.157276] [<c1040524>] ?
> kthread_worker_fn+0x101/0x101
> Oct 16 21:31:43 localhost kernel: [14328.160671] [<c1249a76>] ?
> kernel_thread_helper+0x6/0xd
> Oct 16 21:31:43 localhost kernel: [14328.164032] handlers:
> Oct 16 21:31:43 localhost kernel: [14328.167331] [<c1068080>]
> irq_default_primary_handler threaded [<ef7eccd5>] usb_hcd_irq
> Oct 16 21:31:43 localhost kernel: [14328.168325] [<c1068080>]
> irq_default_primary_handler threaded [<ef7eccd5>] usb_hcd_irq
> Oct 16 21:31:43 localhost kernel: [14328.168325] [<c1068080>]
> irq_default_primary_handler threaded [<ef7eccd5>] usb_hcd_irq
> Oct 16 21:31:43 localhost kernel: [14328.168325] [<c1068080>]
> irq_default_primary_handler threaded [<ef7eccd5>] usb_hcd_irq
> Oct 16 21:31:43 localhost kernel: [14328.168325] [<c1068080>]
> irq_default_primary_handler threaded [<ef9a54d9>] rtl8169_interrupt
> Oct 16 21:31:43 localhost kernel: [14328.183633] Disabling IRQ #18
>
> This happend repeatedly until I disabled threadirqs option. Now it is stable,
> however I returned to high latencies and terrific iowaits...
>
> Please suggest how cold I get help?
^ permalink raw reply
* Re: Profiling sleep times?
From: Andrew Wagin @ 2011-10-22 16:22 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: Arun Sharma, Peter Zijlstra, Ingo Molnar, linux-perf-users, acme,
Stephane Eranian
In-Reply-To: <20111022104947.GB2811@somewhere.feld.cvut.cz>
Hi, All.
Sorry for late response. I have vacation.
I see the miscomuniction. You explained me, that remote callchains was
not a good idea and now I think the same. I added plugin to "perf
inject".
The example of usage:
#./perf record -ag -e sched:sched_switch --filter "prev_state == 1" -e
sched:sched_process_exit -e sched:sched_stat_sleep --filter "comm ==
foo" ~/foo
#./perf inject -s -i perf.data -o perf.data.d
#./perf report -i perf.data.d
I'm going to send patches soon.
2011/10/22 Frederic Weisbecker <fweisbec@gmail.com>:
> On Mon, Oct 17, 2011 at 06:07:00PM -0700, Arun Sharma wrote:
>> On 10/15/11 12:29 PM, Peter Zijlstra wrote:
>> >On Sat, 2011-10-15 at 21:22 +0200, Peter Zijlstra wrote:
>> >
>> >>>Sleep time should really just be a different notion of 'cost of the
>> >>>function/callchain' and fit into the existing scheme, right?
>> >>
>> >>The problem with andrew's patches is that it wrecks the callchain
>> >>semantics. The waittime tracepoint is in the wakeup path (and hence
>> >>generates the wakee's callchain) whereas they really want the callchain
>> >>of the woken task to show where it spend time.
>> >
>> >We could of course try to move the tracepoint into the schedule path, so
>> >we issue it the first time the task gets scheduled after the wakeup, but
>> >I suspect that will just add more overhead, and we really could do
>> >without that.
>>
>> Do we need to define new tracepoints? I suspect we could make the
>> existing ones:
>>
>> trace_sched_stat_wait()
>> trace_sched_stat_sleep()
>>
>> work for this purpose. The length of time the task was not on the
>> cpu could then be computed as: sleep+wait. The downside is that the
>> complexity moves to user space.
>>
>> perf record -e sched:sched_stat_sleep,sched:sched_stat_wait,...
>>
>> Re: changing the semantics of tracepoint callchains
>>
>> Yeah - this could be surprising. Luckily, most tracepoints retain
>> their semantics, but a few special ones don't. I guess we just need
>> to document the new behavior.
>
> That's not only a problem of semantics although that alone is a problem,
> people will seldom read the documentation for corner cases, we should
> really stay consistant here: if remote callchains are really needed, we
> want a specific interface for that, not abusing the existing one that would
> only confuse people.
>
> Now I still think doing remote callchains is asking for troubles: we need to
> ensure the target is really sleeping and is not going to be scheduled
> concurrently otherwise you might get weird or stale results. So the user needs
> to know which tracepoints are safe to perform this.
> Then comes the problem to deal with remote callchains in userspace: the event
> comes from a task but the callchain is from another. You need the perf tools
> to handle remote dsos/mapping/sym etc...
>
> That's a lot of unnecessary complications.
>
> I think we should use something like a perf report plugin: perhaps something
> that can create a virtual event on top of real ones: compute the sched:sched_switch
> events, find the time tasks are sleeping and create virtual sleep events on top
> of that with a period weighted with the sleep time.
> Just a thought.
>
^ permalink raw reply
* [Bug 39513] sensors are inaccessible on radeon 9600xt agp
From: bugzilla-daemon @ 2011-10-22 16:17 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-39513-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=39513
--- Comment #17 from auxsvr@gmail.com 2011-10-22 09:17:54 PDT ---
I'm running kernel 3.1rc9, asus 9600xt and the f75375 sensor is detected, yet
the readings are obviously wrong and constant:
f75375-i2c-3-28
Adapter: Radeon i2c bit bus MONID
in0: +2.00 V (min = +2.00 V, max = +2.00 V)
in1: +2.00 V (min = +2.00 V, max = +2.00 V)
in2: +2.00 V (min = +2.00 V, max = +2.00 V)
in3: +2.00 V (min = +2.00 V, max = +2.00 V)
fan1: 22 RPM (min = 1000 RPM)
fan2: 22 RPM (min = 1000 RPM)
temp1: -6.0°C (high = +65.0°C, hyst = +50.0°C)
temp2: -6.0°C (high = +70.0°C, hyst = +50.0°C)
Is there any special configuration needed?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [B.A.T.M.A.N.] [PATCH] batman-adv: directly write tt entries without buffering
From: Simon Wunderlich @ 2011-10-22 16:15 UTC (permalink / raw)
To: b.a.t.m.a.n; +Cc: Simon Wunderlich
When the translation tables (global and local) are written for debugfs,
it is not neccesary to allocate a buffer, we can directly use
seq_printf() to print them out.
This might actually be safer if the table changes between size
calculation and traversal, and we can't estimate the required size
wrong.
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
---
translation-table.c | 57 +-------------------------------------------------
1 files changed, 2 insertions(+), 55 deletions(-)
diff --git a/translation-table.c b/translation-table.c
index c2af2b1..fadbc05 100644
--- a/translation-table.c
+++ b/translation-table.c
@@ -302,8 +302,6 @@ int tt_local_seq_print_text(struct seq_file *seq, void *offset)
struct hard_iface *primary_if;
struct hlist_node *node;
struct hlist_head *head;
- size_t buf_size, pos;
- char *buff;
uint32_t i;
int ret = 0;
@@ -326,34 +324,13 @@ int tt_local_seq_print_text(struct seq_file *seq, void *offset)
"announced via TT (TTVN: %u):\n",
net_dev->name, (uint8_t)atomic_read(&bat_priv->ttvn));
- buf_size = 1;
- /* Estimate length for: " * xx:xx:xx:xx:xx:xx\n" */
- for (i = 0; i < hash->size; i++) {
- head = &hash->table[i];
-
- rcu_read_lock();
- __hlist_for_each_rcu(node, head)
- buf_size += 29;
- rcu_read_unlock();
- }
-
- buff = kmalloc(buf_size, GFP_ATOMIC);
- if (!buff) {
- ret = -ENOMEM;
- goto out;
- }
-
- buff[0] = '\0';
- pos = 0;
-
for (i = 0; i < hash->size; i++) {
head = &hash->table[i];
rcu_read_lock();
hlist_for_each_entry_rcu(tt_local_entry, node,
head, hash_entry) {
- pos += snprintf(buff + pos, 30, " * %pM "
- "[%c%c%c%c%c]\n",
+ seq_printf(seq, " * %pM [%c%c%c%c%c]\n",
tt_local_entry->addr,
(tt_local_entry->flags &
TT_CLIENT_ROAM ? 'R' : '.'),
@@ -368,9 +345,6 @@ int tt_local_seq_print_text(struct seq_file *seq, void *offset)
}
rcu_read_unlock();
}
-
- seq_printf(seq, "%s", buff);
- kfree(buff);
out:
if (primary_if)
hardif_free_ref(primary_if);
@@ -579,8 +553,6 @@ int tt_global_seq_print_text(struct seq_file *seq, void *offset)
struct hard_iface *primary_if;
struct hlist_node *node;
struct hlist_head *head;
- size_t buf_size, pos;
- char *buff;
uint32_t i;
int ret = 0;
@@ -605,35 +577,13 @@ int tt_global_seq_print_text(struct seq_file *seq, void *offset)
seq_printf(seq, " %-13s %s %-15s %s %s\n",
"Client", "(TTVN)", "Originator", "(Curr TTVN)", "Flags");
- buf_size = 1;
- /* Estimate length for: " * xx:xx:xx:xx:xx:xx (ttvn) via
- * xx:xx:xx:xx:xx:xx (cur_ttvn)\n"*/
- for (i = 0; i < hash->size; i++) {
- head = &hash->table[i];
-
- rcu_read_lock();
- __hlist_for_each_rcu(node, head)
- buf_size += 67;
- rcu_read_unlock();
- }
-
- buff = kmalloc(buf_size, GFP_ATOMIC);
- if (!buff) {
- ret = -ENOMEM;
- goto out;
- }
-
- buff[0] = '\0';
- pos = 0;
-
for (i = 0; i < hash->size; i++) {
head = &hash->table[i];
rcu_read_lock();
hlist_for_each_entry_rcu(tt_global_entry, node,
head, hash_entry) {
- pos += snprintf(buff + pos, 69,
- " * %pM (%3u) via %pM (%3u) "
+ seq_printf(seq, " * %pM (%3u) via %pM (%3u) "
"[%c%c%c]\n", tt_global_entry->addr,
tt_global_entry->ttvn,
tt_global_entry->orig_node->orig,
@@ -649,9 +599,6 @@ int tt_global_seq_print_text(struct seq_file *seq, void *offset)
}
rcu_read_unlock();
}
-
- seq_printf(seq, "%s", buff);
- kfree(buff);
out:
if (primary_if)
hardif_free_ref(primary_if);
--
1.7.7
^ permalink raw reply related
* [U-Boot] [PATCH 0/8] Add tftpput command for uploading files over network
From: Simon Glass @ 2011-10-22 16:15 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4EA27CFE.2010303@aribaud.net>
Hi Albert,
On Sat, Oct 22, 2011 at 1:21 AM, Albert ARIBAUD
<albert.u.boot@aribaud.net> wrote:
> Le 22/10/2011 06:51, Simon Glass a ?crit :
>>
>> The tftpboot command permits reading of files over a network interface
>> using the Trivial FTP protocol. This patch series adds the ability to
>> transfer files the other way.
>>
>> Why is this useful?
>>
>> - Uploading boot time data to a server
>> - Uploading profiling information
>> - Uploading large mounts of data for comparison / checking on a host
>> ? ? (e.g. use tftpput and ghex2 instead of the 'md' command)
>
> Especially I find it interesting for backing up things like MTD and small
> disk files (not partitions, though). Most of my work currently is trying to
> bring mainline U-Boot support to existing boards with bad U-Boot
> implementations, and being able to backup things from U-Boot (as opposed to
> having to set up NFS root and Linux boot) would definitely be a plus.
>
>> Mostly the existing code can be re-used and I have tried to avoid too
>> much refactoring or cleaning up.
>
> :)
>
>> The feature is activated by the CONFIG_CMD_TFTPPUT option.
>>
>> This has been very lightly tested on a Seaboard with a USB network
>> adaptor. I don't think it handles block number overflow.
>
> What size does this limit transfers to?
I think about 1468 * 65535 - around 95MB - it's fairly easy to fix
just by copying out the existing tftp get wrap code. I put it in the
commit message so it wouldn't get lost.
>
>> Simon Glass (8):
>> ? Move simple_itoa to vsprintf
>> ? Add setenv_uint() and setenv_addr()
>> ? tftpput: Rename TFTP to TFTPGET
>> ? tftpput: move common code into separate functions
>> ? tftpput: support selecting get/put for tftp
>> ? tftpput: add save_addr and save_size global variables
>> ? tftpput: implement tftp logic
>> ? tftpput: add tftpput command
>
> Many U-Boot environments use 'tftp' as a shorthand to tftpboot. Did you
> verify that this is not broken by the introduction of 'tftpput'?
>
> Also, I'd be happy to test this if a branch exists that already holds these
> commits.
I will see if I can organise one at Denx.
Regards,
Simon
>
> Amicalement,
> --
> Albert.
>
^ permalink raw reply
* [U-Boot] [PATCH 3/9] arm: Move CP15 init out of cpu_init_crit()
From: Simon Glass @ 2011-10-22 16:13 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4EA27738.4060102@aribaud.net>
Hi Albert,
On Sat, Oct 22, 2011 at 12:56 AM, Albert ARIBAUD
<albert.u.boot@aribaud.net> wrote:
> Le 22/10/2011 07:05, Simon Glass a ?crit :
>
>>>> Well I actually haven't moved it! It is just that previously it was
>>>> impossible to call cp15_init from anywhere later.
>>>
>>> It is moved, in that it belongs to low level init... of A9.
>>
>> OK, I see - you mean moved in order if not in source code file.
>
> Yes. In the code, though, it belongs to low-level init.
Arguably this could go in a library like arch/arm/cpu/armv7/lib/cache.S
>
>>>> What you say can be done, it would involve some assembler though and
>>>> would need to be another CONFIG option. Was trying to avoid adding new
>>>> assembler.
>>>
>>> Low level init is about assembler and, well, low level. :)
>>
>> Yes but it's yuck. Part of the clean-up is to remove most of the
>> assembler - really very little is needed.
>
> I don't think "yuck" is a valid reasoned argument against assembly language
> :) but I assume what you mainly mean is 'hard to understand and replaceable
> by easy to understand C code'. I agree to the first part, and to the second
> one for the general case, but not for the startup path where, precisely, we
> don't have a working C run-time and most of the understanding requires
> knowledge of hardware, not only general programming knowledge. Past that, C
I'm not arguing for the cache init stuff to move to C, just trying to
avoid any creeping growth of assembler when C can do it.
> is ok -- but then beware: some C++ guy could chime in and contend that C is
> "yuck" by your own standards. :)
The C++ guy who finds himself in U-Boot is probably lost :-)
>
>>> But I don't see why there should be another CONFIG option. IIUC, you
>>> should
>>> be able to do with only CONFIG_SKIP_LOWLEVEL_INIT: within the low level
>>> init
>>> code under it, you would do the equivalent of a switch, with one branch
>>> for
>>> AVM (and DDR init etc) and one branch for A9 (with cp15 init etc).
>>
>> Yes I can, but I need to be able to call cp15_init. And I can't do
>> that because if CONFIG_SKIP_LOWLEVEL_INIT is defined, that code is
>> compiled out! So I need to move that cp15_init code outside the
>> CONFIG_SKIP_LOWLEVEL_INIT #ifdef. That is all I am trying to do,
>> honest!
>
> I understand, and I think the approach here is wrong, because you *do* want
> low-level init in the A9 case, and thus you should not have
> CONFIG_SKIP_LOWLEVEL_INIT set. But you also need the AVP low-level init to
> be empty, and the AVP and A9 must follow the same startup path. And all this
> it not necessarily required for all armv7 platforms, but some of them will
> want lowlevel init, and some not. Considering all this...
>
> For now, I would opt for a CONFIG_ARCH_GENERIC_LOWLEVEL_INIT option which
> start.S would use to compile out the low level init code definition (like
> CONFIG_SKIP_LOWLEVEL_INIT does) but not the the calls to it (UNline
> CONFIG_SKIP_LOWLEVEL_INIT does). Then you could provide a SoC-specific
> version of lowlevel_init.
If I understand you correctly, this is the opposite of what I want. It
is basically what we have now.
All ARMv7 chips are going to turn off MMU, caches, flush TLBs, and the
like - this is an architecture feature, not an SOC one. We have
conflated ARM arch init with SOC init as you say, but the solution is
not to force the SOC to copy code from start.S just so that it can do
ARM arch init later.
And I'd argue for LOWLEVEL_INIT being about setting up the memory so
we can run code, and in particular relocate it later. The cp15_init
stuff should arguably be in arch_cpu_init() (or perhaps a new
arch_init()) as the first thing called from board_init_f() in my view.
So how about I create a patch to move the cp15_init() code into
arch/arm/cpu/armv7/lib/lowlevel.S or similar so I can call it later?
>
> In the longer term, I would be more in favor of a weak definition system
> with hierarchical ARCH, ISA, SoC, board priority order (yes, I am kind of
> fond of it) for lowlevel init -- but that will require looking into asm weak
> symbol handling and may require splitting of the assembly code function by
> function.
I think you are trying to avoid the
#ifdef CONFIG_ARCH_CPU_INIT
arch_cpu_init,
#endif
#ifdef ...
some_other_thing
#endif
in the board_init_f() function table. Yes I agree it would tidy things
up, although I wonder if Graeme's initcall thing isn't better again.
It has the same confusion level coefficient (only the linker decides
what code is included) with a bit more flexibility. Then each arch /
board / cpu / soc / squirrel can decide on its own init and put it in
its own file. C only please :-)
Regards,
Simon
>
>> Regards,
>> Simon
>
> Amicalement,
> --
> Albert.
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.