* [RFC, PATCH 0/5] unify definition of CLOCK_TICK_RATE across different platforms
From: Eric Miao @ 2010-10-20 6:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20101020045110.GW12979@mail.wantstofly.org>
On Wed, Oct 20, 2010 at 12:51 PM, Lennert Buytenhek
<buytenh@wantstofly.org> wrote:
> One of the things preventing building an ARM multiplatform kernel
> image is the fact that CLOCK_TICK_RATE (and as a consequence, LATCH)
> is defined differently for each ARM platform.
>
> The patches in this series:
> - pull the per-platform CLOCK_TICK_RATE defines from <mach/timex.h>
> ?into arch/arm/mach-foo/ (on those platforms that use the
> ?CLOCK_TICK_RATE define and/or the LATCH define in their platform
> ?support code);
> - define CLOCK_TICK_RATE as a platform-independent value in <asm/timex.h>;
> - get rid of all <mach/timex.h> include files.
>
Excellent!
^ permalink raw reply
* Re: [PATCH 2/2] sysctl: remove sysctl syscall
From: Cong Wang @ 2010-10-20 6:06 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Andi Kleen, linux-kernel, Randy Dunlap, Mauro Carvalho Chehab,
Len Brown, Ingo Molnar, Andrew Morton, David Howells, Eric Paris,
Peter Zijlstra, Eric Dumazet, David S. Miller, Andy Shevchenko,
linux-doc
In-Reply-To: <m1eibmdvew.fsf@fess.ebiederm.org>
On 10/20/10 00:00, Eric W. Biederman wrote:
> To the best of my knowledge the last and user of sys_sysctl is the glibc
> ioperm (my apologies I mispoke when I said iopl) implementation on arm.
> Not that people run around calling ioperm very often in any distro.
I saw that in Changelog of glibc too, but that was back to 2000, 10 years
past, I don't see any code using sysctl() in glibc now, except sys_sysctl()
itself, of course.
>
> All of that said I think disabling sys_sysctl by default now is totally
> reasonable. If there is a percentage in removing the code we can worry
> about that later. Perhaps we should add a CONFIG_CRUFT and move
> sys_sysctl under there. Binary compatibility that nothing needs but
> that we actually have code for just in case.
But you put sysctl in features-removal-schedule.txt 3 years ago. :)
I believe they should see the kernel warnings if they are still using
sysctl.
Thanks.
^ permalink raw reply
* [U-Boot] [PATCH] kirkwood: Fix Makefile TEXT_BASE for mkimage
From: Prafulla Wadaskar @ 2010-10-20 6:03 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4CBD9A9E.1080805@rocketmail.com>
Hi Gray
It will be great if you put some comments too.
That to describe patch objective
Regards..
Prafulla . .
> -----Original Message-----
> From: u-boot-bounces at lists.denx.de
> [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Gray Remlin
> Sent: Tuesday, October 19, 2010 6:48 PM
> To: u-boot at lists.denx.de
> Subject: [U-Boot] [PATCH] kirkwood: Fix Makefile TEXT_BASE for mkimage
>
>
> Signed-off-by: Gray Remlin <g_remlin@rocketmail.com>
> ---
> Makefile | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 30a564d..a3136da 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -341,7 +341,7 @@ $(obj)u-boot.imx: $(obj)u-boot.bin
>
> $(obj)u-boot.kwb: $(obj)u-boot.bin
> $(obj)tools/mkimage -n $(KWD_CONFIG) -T kwbimage \
> - -a $(CONFIG_SYS_TEXT_BASE) -e $(TEXT_BASE) -d $< $@
> + -a $(CONFIG_SYS_TEXT_BASE) -e
> $(CONFIG_SYS_TEXT_BASE) -d
> $< $@
>
> $(obj)u-boot.sha1: $(obj)u-boot.bin
> $(obj)tools/ubsha1 $(obj)u-boot.bin
> --
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
^ permalink raw reply
* [PATCH 3/5] rtc-pxa: remove unused TIMER_FREQ define
From: Eric Miao @ 2010-10-20 6:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20101020045141.GZ12979@mail.wantstofly.org>
On Wed, Oct 20, 2010 at 12:51 PM, Lennert Buytenhek
<buytenh@wantstofly.org> wrote:
> Signed-off-by: Lennert Buytenhek <buytenh@secretlab.ca>
Acked-by: Eric Miao <eric.miao@canonical.com>
> ---
> ?drivers/rtc/rtc-pxa.c | ? ?1 -
> ?1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/rtc/rtc-pxa.c b/drivers/rtc/rtc-pxa.c
> index 29e867a..486b72d 100644
> --- a/drivers/rtc/rtc-pxa.c
> +++ b/drivers/rtc/rtc-pxa.c
> @@ -30,7 +30,6 @@
>
> ?#include <mach/hardware.h>
>
> -#define TIMER_FREQ ? ? ? ? ? ? CLOCK_TICK_RATE
> ?#define RTC_DEF_DIVIDER ? ? ? ? ? ? ? ?(32768 - 1)
> ?#define RTC_DEF_TRIM ? ? ? ? ? 0
> ?#define MAXFREQ_PERIODIC ? ? ? 1000
> --
> 1.7.2.3
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* Re: Question/Problem: Mounting of XFS filesystem takes a lot of time
From: Michael Monnerie @ 2010-10-20 6:05 UTC (permalink / raw)
To: xfs; +Cc: Andreas Hasenkopf
In-Reply-To: <1287521058.2000.21.camel@x200>
[-- Attachment #1.1: Type: Text/Plain, Size: 661 bytes --]
On Dienstag, 19. Oktober 2010 Andreas Hasenkopf wrote:
> 2x 1TB HDD in RAID1 configuration (xfs)
Check your disks. I've seen harddisks dying in that way. Suddenly access
times are horrible. Test random access I/O and compare times, not
sequential - those might still look good.
--
mit freundlichen Grüssen,
Michael Monnerie, Ing. BSc
it-management Internet Services
http://proteger.at [gesprochen: Prot-e-schee]
Tel: 0660 / 415 65 31
****** Radiointerview zum Thema Spam ******
http://www.it-podcast.at/archiv.html#podcast-100716
// Wir haben im Moment zwei Häuser zu verkaufen:
// http://zmi.at/langegg/
// http://zmi.at/haus2009/
[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
[-- Attachment #2: Type: text/plain, Size: 121 bytes --]
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* Re: [lm-sensors] [PATCH] drivers/hwmon: Use pr_fmt and pr_<level>
From: Henrik Rydberg @ 2010-10-20 6:04 UTC (permalink / raw)
To: Joe Perches
Cc: Guenter Roeck, Jean Delvare, Hans de Goede,
Alistair John Strachan, Mark M. Hoffman, Luca Tettamanti,
Fenghua Yu, Juerg Haefliger, Eric Piel, Jim Cromie, Roger Lucas,
lm-sensors@lm-sensors.org, LKML
In-Reply-To: <1287547662.10409.618.camel@Joe-Laptop>
On 10/20/2010 06:07 AM, Joe Perches wrote:
> On Tue, 2010-10-19 at 20:53 -0700, Guenter Roeck wrote:
>> On Tue, Oct 19, 2010 at 11:34:18PM -0400, Joe Perches wrote:
>>> On Tue, 2010-10-19 at 20:29 -0700, Guenter Roeck wrote:
>>>> There are several lines longer than 80 characters.
>>>> Does this rule no longer apply ?
>>> 80 columns isn't checked for printk format strings.
>> Interesting.
>>> A kernel general preference may be to keep formats as
>>> a single string without line breaks so that grep works
>>> better.
>>>> Oddly enough, there are only four checkpatch warnings about long lines,
>>>> even though there are many more.
>>> The version I use doesn't show any warnings.
>> checkpatch.pl from both v2.6.36-rc7 and v2.6.36-rc6 do report warnings.
>> Looks like those versions flag long lines for pr_warn. Is your version
>> older or newer ?
>
> Newer. It adds pr_warn to the exempted list, not just pr_warning.
>
>> Anyway, would it be possible to split the patch into one patch per file ?
>
> Oh sure. It's trivial to do that.
>
>> I don't know how Jean thinks about it, but in my opinion it would be cleaner,
>> permit revert on a single patch/file instead of having to revert the entire series,
>> it would simplify review, and it would make it much easier to cherry-pick
>> pieces into other releases if needed.
>
> Jean, do you have a preference?
> I'll resubmit if you want it separated.
Yes please, that would be nice.
Thanks,
Henrik
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply
* Re: [PATCH] drivers/hwmon: Use pr_fmt and pr_<level>
From: Henrik Rydberg @ 2010-10-20 6:04 UTC (permalink / raw)
To: Joe Perches
Cc: Guenter Roeck, Jean Delvare, Hans de Goede,
Alistair John Strachan, Mark M. Hoffman, Luca Tettamanti,
Fenghua Yu, Juerg Haefliger, Eric Piel, Jim Cromie, Roger Lucas,
lm-sensors@lm-sensors.org, LKML
In-Reply-To: <1287547662.10409.618.camel@Joe-Laptop>
On 10/20/2010 06:07 AM, Joe Perches wrote:
> On Tue, 2010-10-19 at 20:53 -0700, Guenter Roeck wrote:
>> On Tue, Oct 19, 2010 at 11:34:18PM -0400, Joe Perches wrote:
>>> On Tue, 2010-10-19 at 20:29 -0700, Guenter Roeck wrote:
>>>> There are several lines longer than 80 characters.
>>>> Does this rule no longer apply ?
>>> 80 columns isn't checked for printk format strings.
>> Interesting.
>>> A kernel general preference may be to keep formats as
>>> a single string without line breaks so that grep works
>>> better.
>>>> Oddly enough, there are only four checkpatch warnings about long lines,
>>>> even though there are many more.
>>> The version I use doesn't show any warnings.
>> checkpatch.pl from both v2.6.36-rc7 and v2.6.36-rc6 do report warnings.
>> Looks like those versions flag long lines for pr_warn. Is your version
>> older or newer ?
>
> Newer. It adds pr_warn to the exempted list, not just pr_warning.
>
>> Anyway, would it be possible to split the patch into one patch per file ?
>
> Oh sure. It's trivial to do that.
>
>> I don't know how Jean thinks about it, but in my opinion it would be cleaner,
>> permit revert on a single patch/file instead of having to revert the entire series,
>> it would simplify review, and it would make it much easier to cherry-pick
>> pieces into other releases if needed.
>
> Jean, do you have a preference?
> I'll resubmit if you want it separated.
Yes please, that would be nice.
Thanks,
Henrik
^ permalink raw reply
* [U-Boot] [PATCH RFC 3/4] ARMV7: OMAP: I2C driver: Restructure i2c_write_byte function
From: Heiko Schocher @ 2010-10-20 6:08 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1287462940-19496-4-git-send-email-steve@sakoman.com>
Hello Steve,
Steve Sakoman wrote:
> This patch removes the "magic number" delays and instead
> monitors state changes in the status register bits.
>
> Signed-off-by: Steve Sakoman <steve.sakoman@linaro.org>
> ---
> drivers/i2c/omap24xx_i2c.c | 76 +++++++++++++++++++++++--------------------
> 1 files changed, 41 insertions(+), 35 deletions(-)
After trying this for the omap3_beagle board, I get an
compiler warning:
[hs at pollux u-boot]$ ./MAKEALL omap3_beagle
Configuring for omap3_beagle board...
omap24xx_i2c.c: In function 'i2c_write_byte':
omap24xx_i2c.c:221: warning: unused variable 'stat'
text data bss dec hex filename
218103 11412 202384 431899 6971b ./u-boot
--------------------- SUMMARY ----------------------------
Boards compiled: 1
Boards with warnings or errors: 1 ( omap3_beagle )
----------------------------------------------------------
[hs at pollux u-boot]$
following patch fixes it.
BTW:
Just for the record, your patchset works fine and faster
on the beagle board, for example:
before your after your
patchset patchset
i2c probe 9s 0,4s
i2c md 48 0 100 17s 1s
would you post a v2 of this patch, and I add my
"Tested-by" to it, or is it OK, if I add my fix patch
to u-boot-i2c master?
^ permalink raw reply
* [Ocfs2-devel] [RFC] ocfs2: Remove j_trans_barrier
From: Tao Ma @ 2010-10-20 6:08 UTC (permalink / raw)
To: ocfs2-devel
Hi all,
j_trans_barrier in ocfs2 is used to protect some journal operations in
ocfs2. So normally, it is used as belows:
1. In journal transaction. When we start a transaction, We will
down_read it and j_num_trans will be increased accordingly(in case of a
cluster environment). It will be up_read when we do ocfs2_commit_trans.
2. In ocfs2_commit_cache, we will down_write it and then call
jbd2_journal_flush, increase j_trans_id, reset j_num_trans and finally
call up_write. This function is used by thread ocfs2cmt.
So in general, when we do journal flush, no new transaction will be
started because of it. But it did hold off the system and caused a long
delay for some file operations. I have met with a bug.
http://oss.oracle.com/bugzilla/show_bug.cgi?id=1281
After 30 days of usage of ocfs2, the system becomes slower and
slower(why the journal commit becomes so slower is still unknown and may
be related to file system fragmentation) and a tiny open/truncate of a
file will cause around 10-30 secs. I don't think it is endurable for a
user. After putting some debug codes in the kernel(great thanks to the
user), I find that it is the blocked by ocfs2_start_trans. The strace
log shows:
22955 open("/usr/home/test_io_file_ow", O_WRONLY|O_CREAT|O_TRUNC, 0666)
= 1 <10.329676>
And from the system log:
Sep 24 17:28:30 192.168.0.4 kernel:
(dd,22955,5):ocfs2_orphan_for_truncate:354 start transcation for inode
105572512
Sep 24 17:28:41 192.168.0.4 kernel:
(dd,22955,5):ocfs2_orphan_for_truncate:362 journal access for inode
105572512
The code is like this:
mlog(0, "start transcation for inode %llu\n", OCFS2_I(inode)->ip_blkno);
handle = ocfs2_start_trans(osb, OCFS2_INODE_UPDATE_CREDITS);
if (IS_ERR(handle)) {
status = PTR_ERR(handle);
mlog_errno(status);
goto out;
}
mlog(0, "journal access for inode %llu\n",
OCFS2_I(inode)->ip_blkno);
So we spent 11 secs in ocfs2_start_trans!
From what I have investigated, j_trans_barrier is only used in a
cluster environment(for a local mounted volume, ocfs2cmt isn't started
and we depends on jbd2 to flush the journal). And it works with
j_trans_id to make sure all the modifications to the specified
ocfs2_caching_info are flushed(see ocfs2_ci_fully_checkpointed) when we
downconvert a cluster lock. And we also call ocfs2_set_ci_lock_trans in
journal_access so that we know the last trans_id for a specified
ocfs2_caching_info.
My solution is that:
1. remove j_trans_barrier
2. Add a flag ci_checkpointing in ocfs2_caching_info:
1) When we find this caching_info needs checkpoint, set this flag
and start the checkpointing(in ocfs2_ci_checkpointed). And the
downconvert request will be requeued so that we can check and clear this
flag next time it is handled.
2) Clear the flag when there is no need for checkpointing this
ci(also in ocfs2_ci_checkpointed) during check_downconvert.
3. make sure when we journal_access some blocks, the caching_info can't
be in the state of checkpointing. I think if we are checkpointing an
caching_info, we shouldn't be able to journal_access it since it is just
required to downconvert and we shouldn't have the lock now? So perhaps a
BUG_ON should work?
So above is the scenario and my solution. Any comments are welcomed.
Regards,
Tao
^ permalink raw reply
* Re: Call for help for demo UPNP media renderer
From: Xu, Dongxiao @ 2010-10-20 6:07 UTC (permalink / raw)
To: Joshua Lock; +Cc: yocto@yoctoproject.org
In-Reply-To: <D5AB6E638E5A3E4B8F4406B113A5A19A2FF0D2C6@shsmsx501.ccr.corp.intel.com>
Hi Josh,
Today I took a glance at the rygel crash issue in poky. Though I didn't get the root cause, I found when configure Tracker plugin into rygel, the segmentation fault will happen. Since we have already configured the media-export plugin, and tracker plugin plays the same role, I think we can simply disable tracker plugin (by configure time or change by rygel-preferences) for demo usage.
Thanks,
Dongxiao
Xu, Dongxiao wrote:
> I just built out the poky-image-rygel image with your meta-demo
> layer, and run
>
> rygel --gst-debug-level=5
>
> I still saw it "segmentation fault" in the last...
>
> I am looking into it.
>
> Thanks,
> Dongxiao
>
> Xu, Dongxiao wrote:
>> Zanussi, Tom wrote:
>>> On Tue, 2010-10-19 at 17:40 -0700, Xu, Dongxiao wrote:
>>>> Joshua Lock wrote:
>>>>> On Wed, 2010-10-20 at 01:04 +0100, Joshua Lock wrote:
>>>>>> On Tue, 2010-10-19 at 14:31 -0700, Saul Wold wrote:
>>>>>>>
>>>>>>> Dongxiao,
>>>>>>>
>>>>>>> Can you take a look at this since you have worked with the
>>>>>>> gstreamer?
>>>>>>
>>>>>> I did a sloppy job pushing my changes when leaving the office but
>>>>>> think I have replicated most/all of the in the josh/demo branch.
>>>>>>
>>>>>> I also took a look through the rygel code to see what gstreamer
>>>>>> elements are explicitly being used, I've created a list and tried
>>>>>> to ensure as many as possible of them are in the IMAGE_INSTALL
>>>>>> list for poky-image-rygel, adding them to the RDEPENDS for rygel
>>>>>> doesn't appear to have included them in the image I just
>>>>>> created...
>>>>>>
>>>>>> Full list of names of pipeline elements I found in the rygel
>>>>>> code follows:
>>>>>>
>>>>>> decodebin2, videorate, videoscale, ffmpegcolorspace, ffenc_wmv1,
>>>>>> twolame, lame, mp3parse, ffenc_wmav2, convert-sink-pad,
>>>>>> ffenc_mpeg2video, audio-src-pad, audio-sink-pad,
>>>>>> audio-enc-sink-pad, sink, mpegtsmux, audioconvert, audioresample,
>>>>>> audiorate, capsfilter, audiotestsrc, videotestsrc, ffmux_asf
>>>>>>
>>>>>
>>>>> The image I just built with my latest changes in josh/demo
>>>>> worked!?! Rygel did not segfault :-)
>>>>>
>>>>> If you have time Dongxiao (or anyone else) I'd appreciate if you
>>>>> could double-check my changes (my install_append in rygel to
>>>>> create a .config isn't working, so you'll need to do that
>>>>> manually and run rygel-preferences to disable the tracker
>>>>> plugin). If you could test using Rygel as a renderer for some
>>>>> content served by the mediatomb image, that would be much
>>>>> appreciated. You'll want gupnp-av-cp as provided by gupnp-tools
>>>>> to control the renderer and content server.
>>>>>
>>>>> Thanks,
>>>>> Joshua
>>>>
>>>> I will try your branch, however I didn't find josh/demo in
>>>> poky-contrib. Is it reside in other place?
>>>>
>>>
>>> It should be here:
>>>
>>> ssh://git@git.pokylinux.org/meta-demo.git
>>>
>>> Tom
>>
>> Got it, thanks!
>>
>> Dongxiao
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.pokylinux.org/listinfo/yocto
^ permalink raw reply
* [PATCH 1/2 v2] rcu,cleanup: move synchronize_sched_expedited() out of sched.c
From: Lai Jiangshan @ 2010-10-20 6:12 UTC (permalink / raw)
To: Paul E. McKenney, Ingo Molnar, LKML
The first version of synchronize_sched_expedited() use the migration code
of the scheduler code, so it have to be implemented in sched.c
but now, the synchronize_sched_expedited() does not use such code,
it is time to move it out of sched.c.
Different rcu implementation' synchronize_sched_expedited() are also
different. so we move synchronize_sched_expedited() to kernel/rcutree_plugin.h
or include/linux/rcutiny.h instead of kerenl/rcupdate.c
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
---
include/linux/rcupdate.h | 1
include/linux/rcutiny.h | 5 +++
include/linux/rcutree.h | 1
kernel/rcutree_plugin.h | 71 +++++++++++++++++++++++++++++++++++++++++++++++
kernel/sched.c | 69 ---------------------------------------------
5 files changed, 77 insertions(+), 70 deletions(-)
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index 0d0b640..ead36da 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -66,7 +66,6 @@ extern void call_rcu_sched(struct rcu_head *head,
extern void synchronize_sched(void);
extern void rcu_barrier_bh(void);
extern void rcu_barrier_sched(void);
-extern void synchronize_sched_expedited(void);
extern int sched_expedited_torture_stats(char *page);
static inline void __rcu_read_lock_bh(void)
diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h
index 13877cb..4d84452 100644
--- a/include/linux/rcutiny.h
+++ b/include/linux/rcutiny.h
@@ -58,6 +58,11 @@ static inline void synchronize_rcu_bh_expedited(void)
synchronize_sched();
}
+static inline void synchronize_sched_expedited(void)
+{
+ synchronize_sched();
+}
+
#ifdef CONFIG_TINY_RCU
static inline void rcu_preempt_note_context_switch(void)
diff --git a/include/linux/rcutree.h b/include/linux/rcutree.h
index 95518e6..9a1fd6c 100644
--- a/include/linux/rcutree.h
+++ b/include/linux/rcutree.h
@@ -47,6 +47,7 @@ static inline void exit_rcu(void)
#endif /* #else #ifdef CONFIG_TREE_PREEMPT_RCU */
extern void synchronize_rcu_bh(void);
+extern void synchronize_sched_expedited(void);
extern void synchronize_rcu_expedited(void);
static inline void synchronize_rcu_bh_expedited(void)
diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
index 0e75d60..1f4cb21 100644
--- a/kernel/rcutree_plugin.h
+++ b/kernel/rcutree_plugin.h
@@ -25,6 +25,7 @@
*/
#include <linux/delay.h>
+#include <linux/stop_machine.h>
/*
* Check the RCU kernel configuration parameters and print informative
@@ -581,6 +582,76 @@ void synchronize_rcu(void)
}
EXPORT_SYMBOL_GPL(synchronize_rcu);
+#ifndef CONFIG_SMP
+
+void synchronize_sched_expedited(void)
+{
+ cond_resched();
+}
+EXPORT_SYMBOL_GPL(synchronize_sched_expedited);
+
+#else /* #ifndef CONFIG_SMP */
+
+static atomic_t synchronize_sched_expedited_count = ATOMIC_INIT(0);
+
+static int synchronize_sched_expedited_cpu_stop(void *data)
+{
+ /*
+ * There must be a full memory barrier on each affected CPU
+ * between the time that try_stop_cpus() is called and the
+ * time that it returns.
+ *
+ * In the current initial implementation of cpu_stop, the
+ * above condition is already met when the control reaches
+ * this point and the following smp_mb() is not strictly
+ * necessary. Do smp_mb() anyway for documentation and
+ * robustness against future implementation changes.
+ */
+ smp_mb(); /* See above comment block. */
+ return 0;
+}
+
+/*
+ * Wait for an rcu-sched grace period to elapse, but use "big hammer"
+ * approach to force grace period to end quickly. This consumes
+ * significant time on all CPUs, and is thus not recommended for
+ * any sort of common-case code.
+ *
+ * Note that it is illegal to call this function while holding any
+ * lock that is acquired by a CPU-hotplug notifier. Failing to
+ * observe this restriction will result in deadlock.
+ */
+void synchronize_sched_expedited(void)
+{
+ int snap, trycount = 0;
+
+ smp_mb(); /* ensure prior mod happens before capturing snap. */
+ snap = atomic_read(&synchronize_sched_expedited_count) + 1;
+ get_online_cpus();
+ while (try_stop_cpus(cpu_online_mask,
+ synchronize_sched_expedited_cpu_stop,
+ NULL) == -EAGAIN) {
+ put_online_cpus();
+ if (trycount++ < 10)
+ udelay(trycount * num_online_cpus());
+ else {
+ synchronize_sched();
+ return;
+ }
+ if (atomic_read(&synchronize_sched_expedited_count) - snap > 0) {
+ smp_mb(); /* ensure test happens before caller kfree */
+ return;
+ }
+ get_online_cpus();
+ }
+ atomic_inc(&synchronize_sched_expedited_count);
+ smp_mb__after_atomic_inc(); /* ensure post-GP actions seen after GP. */
+ put_online_cpus();
+}
+EXPORT_SYMBOL_GPL(synchronize_sched_expedited);
+
+#endif /* #else #ifndef CONFIG_SMP */
+
static DECLARE_WAIT_QUEUE_HEAD(sync_rcu_preempt_exp_wq);
static long sync_rcu_preempt_exp_count;
static DEFINE_MUTEX(sync_rcu_preempt_exp_mutex);
diff --git a/kernel/sched.c b/kernel/sched.c
index abf8440..9dc7775 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -9332,72 +9332,3 @@ struct cgroup_subsys cpuacct_subsys = {
};
#endif /* CONFIG_CGROUP_CPUACCT */
-#ifndef CONFIG_SMP
-
-void synchronize_sched_expedited(void)
-{
- barrier();
-}
-EXPORT_SYMBOL_GPL(synchronize_sched_expedited);
-
-#else /* #ifndef CONFIG_SMP */
-
-static atomic_t synchronize_sched_expedited_count = ATOMIC_INIT(0);
-
-static int synchronize_sched_expedited_cpu_stop(void *data)
-{
- /*
- * There must be a full memory barrier on each affected CPU
- * between the time that try_stop_cpus() is called and the
- * time that it returns.
- *
- * In the current initial implementation of cpu_stop, the
- * above condition is already met when the control reaches
- * this point and the following smp_mb() is not strictly
- * necessary. Do smp_mb() anyway for documentation and
- * robustness against future implementation changes.
- */
- smp_mb(); /* See above comment block. */
- return 0;
-}
-
-/*
- * Wait for an rcu-sched grace period to elapse, but use "big hammer"
- * approach to force grace period to end quickly. This consumes
- * significant time on all CPUs, and is thus not recommended for
- * any sort of common-case code.
- *
- * Note that it is illegal to call this function while holding any
- * lock that is acquired by a CPU-hotplug notifier. Failing to
- * observe this restriction will result in deadlock.
- */
-void synchronize_sched_expedited(void)
-{
- int snap, trycount = 0;
-
- smp_mb(); /* ensure prior mod happens before capturing snap. */
- snap = atomic_read(&synchronize_sched_expedited_count) + 1;
- get_online_cpus();
- while (try_stop_cpus(cpu_online_mask,
- synchronize_sched_expedited_cpu_stop,
- NULL) == -EAGAIN) {
- put_online_cpus();
- if (trycount++ < 10)
- udelay(trycount * num_online_cpus());
- else {
- synchronize_sched();
- return;
- }
- if (atomic_read(&synchronize_sched_expedited_count) - snap > 0) {
- smp_mb(); /* ensure test happens before caller kfree */
- return;
- }
- get_online_cpus();
- }
- atomic_inc(&synchronize_sched_expedited_count);
- smp_mb__after_atomic_inc(); /* ensure post-GP actions seen after GP. */
- put_online_cpus();
-}
-EXPORT_SYMBOL_GPL(synchronize_sched_expedited);
-
-#endif /* #else #ifndef CONFIG_SMP */
^ permalink raw reply related
* [PATCH 2/2 v2] rcu,cleanup: simplify the code when cpu is dying
From: Lai Jiangshan @ 2010-10-20 6:13 UTC (permalink / raw)
To: Paul E. McKenney, Ingo Molnar, LKML
When we handle cpu notify DYING, the whole system is stopped except
current CPU, so we can touch any data, and we remove the orphan_cbs_tail
and send the callbacks to the dest CPU directly.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
---
rcutree.c | 81 ++++++++++++++-----------------------------------------
rcutree.h | 16 ++--------
rcutree_plugin.h | 8 ++---
rcutree_trace.c | 4 +-
4 files changed, 31 insertions(+), 78 deletions(-)
diff --git a/kernel/rcutree.c b/kernel/rcutree.c
index ccdc04c..669d7fe 100644
--- a/kernel/rcutree.c
+++ b/kernel/rcutree.c
@@ -67,9 +67,6 @@ static struct lock_class_key rcu_node_class[NUM_RCU_LVLS];
.gpnum = -300, \
.completed = -300, \
.onofflock = __RAW_SPIN_LOCK_UNLOCKED(&structname.onofflock), \
- .orphan_cbs_list = NULL, \
- .orphan_cbs_tail = &structname.orphan_cbs_list, \
- .orphan_qlen = 0, \
.fqslock = __RAW_SPIN_LOCK_UNLOCKED(&structname.fqslock), \
.n_force_qs = 0, \
.n_force_qs_ngp = 0, \
@@ -984,53 +981,31 @@ rcu_check_quiescent_state(struct rcu_state *rsp, struct rcu_data *rdp)
#ifdef CONFIG_HOTPLUG_CPU
/*
- * Move a dying CPU's RCU callbacks to the ->orphan_cbs_list for the
- * specified flavor of RCU. The callbacks will be adopted by the next
- * _rcu_barrier() invocation or by the CPU_DEAD notifier, whichever
- * comes first. Because this is invoked from the CPU_DYING notifier,
- * irqs are already disabled.
+ * Move a dying CPU's RCU callbacks to online CPU's callback list.
+ * Synchronization is not required because this function executes
+ * in stop_machine() context.
*/
-static void rcu_send_cbs_to_orphanage(struct rcu_state *rsp)
+static void rcu_send_cbs_to_online(struct rcu_state *rsp)
{
int i;
+ /* current DYING CPU is cleared in the cpu_online_mask */
+ int receive_cpu = cpumask_any(cpu_online_mask);
struct rcu_data *rdp = this_cpu_ptr(rsp->rda);
+ struct rcu_data *receive_rdp = per_cpu_ptr(rsp->rda, receive_cpu);
if (rdp->nxtlist == NULL)
return; /* irqs disabled, so comparison is stable. */
- raw_spin_lock(&rsp->onofflock); /* irqs already disabled. */
- *rsp->orphan_cbs_tail = rdp->nxtlist;
- rsp->orphan_cbs_tail = rdp->nxttail[RCU_NEXT_TAIL];
+
+ *receive_rdp->nxttail[RCU_NEXT_TAIL] = rdp->nxtlist;
+ receive_rdp->nxttail[RCU_NEXT_TAIL] = rdp->nxttail[RCU_NEXT_TAIL];
+ receive_rdp->qlen += rdp->qlen;
+ receive_rdp->n_cbs_adopted += rdp->qlen;
+ rdp->n_cbs_orphaned += rdp->qlen;
+
rdp->nxtlist = NULL;
for (i = 0; i < RCU_NEXT_SIZE; i++)
rdp->nxttail[i] = &rdp->nxtlist;
- rsp->orphan_qlen += rdp->qlen;
- rdp->n_cbs_orphaned += rdp->qlen;
rdp->qlen = 0;
- raw_spin_unlock(&rsp->onofflock); /* irqs remain disabled. */
-}
-
-/*
- * Adopt previously orphaned RCU callbacks.
- */
-static void rcu_adopt_orphan_cbs(struct rcu_state *rsp)
-{
- unsigned long flags;
- struct rcu_data *rdp;
-
- raw_spin_lock_irqsave(&rsp->onofflock, flags);
- rdp = this_cpu_ptr(rsp->rda);
- if (rsp->orphan_cbs_list == NULL) {
- raw_spin_unlock_irqrestore(&rsp->onofflock, flags);
- return;
- }
- *rdp->nxttail[RCU_NEXT_TAIL] = rsp->orphan_cbs_list;
- rdp->nxttail[RCU_NEXT_TAIL] = rsp->orphan_cbs_tail;
- rdp->qlen += rsp->orphan_qlen;
- rdp->n_cbs_adopted += rsp->orphan_qlen;
- rsp->orphan_cbs_list = NULL;
- rsp->orphan_cbs_tail = &rsp->orphan_cbs_list;
- rsp->orphan_qlen = 0;
- raw_spin_unlock_irqrestore(&rsp->onofflock, flags);
}
/*
@@ -1081,8 +1056,6 @@ static void __rcu_offline_cpu(int cpu, struct rcu_state *rsp)
raw_spin_unlock_irqrestore(&rnp->lock, flags);
if (need_report & RCU_OFL_TASKS_EXP_GP)
rcu_report_exp_rnp(rsp, rnp);
-
- rcu_adopt_orphan_cbs(rsp);
}
/*
@@ -1100,11 +1073,7 @@ static void rcu_offline_cpu(int cpu)
#else /* #ifdef CONFIG_HOTPLUG_CPU */
-static void rcu_send_cbs_to_orphanage(struct rcu_state *rsp)
-{
-}
-
-static void rcu_adopt_orphan_cbs(struct rcu_state *rsp)
+static void rcu_send_cbs_to_online(struct rcu_state *rsp)
{
}
@@ -1702,10 +1671,7 @@ static void _rcu_barrier(struct rcu_state *rsp,
* early.
*/
atomic_set(&rcu_barrier_cpu_count, 1);
- preempt_disable(); /* stop CPU_DYING from filling orphan_cbs_list */
- rcu_adopt_orphan_cbs(rsp);
on_each_cpu(rcu_barrier_func, (void *)call_rcu_func, 1);
- preempt_enable(); /* CPU_DYING can again fill orphan_cbs_list */
if (atomic_dec_and_test(&rcu_barrier_cpu_count))
complete(&rcu_barrier_completion);
wait_for_completion(&rcu_barrier_completion);
@@ -1831,18 +1797,13 @@ static int __cpuinit rcu_cpu_notify(struct notifier_block *self,
case CPU_DYING:
case CPU_DYING_FROZEN:
/*
- * preempt_disable() in _rcu_barrier() prevents stop_machine(),
- * so when "on_each_cpu(rcu_barrier_func, (void *)type, 1);"
- * returns, all online cpus have queued rcu_barrier_func().
- * The dying CPU clears its cpu_online_mask bit and
- * moves all of its RCU callbacks to ->orphan_cbs_list
- * in the context of stop_machine(), so subsequent calls
- * to _rcu_barrier() will adopt these callbacks and only
- * then queue rcu_barrier_func() on all remaining CPUs.
+ * The whole machine is "stopped" except this cpu, so we can
+ * touch any data without introducing corruption. And we send
+ * the callbacks to an attribute chosen online cpu.
*/
- rcu_send_cbs_to_orphanage(&rcu_bh_state);
- rcu_send_cbs_to_orphanage(&rcu_sched_state);
- rcu_preempt_send_cbs_to_orphanage();
+ rcu_send_cbs_to_online(&rcu_bh_state);
+ rcu_send_cbs_to_online(&rcu_sched_state);
+ rcu_preempt_send_cbs_to_online();
break;
case CPU_DEAD:
case CPU_DEAD_FROZEN:
diff --git a/kernel/rcutree.h b/kernel/rcutree.h
index 91d4170..1a54be2 100644
--- a/kernel/rcutree.h
+++ b/kernel/rcutree.h
@@ -203,8 +203,8 @@ struct rcu_data {
long qlen_last_fqs_check;
/* qlen at last check for QS forcing */
unsigned long n_cbs_invoked; /* count of RCU cbs invoked. */
- unsigned long n_cbs_orphaned; /* RCU cbs sent to orphanage. */
- unsigned long n_cbs_adopted; /* RCU cbs adopted from orphanage. */
+ unsigned long n_cbs_orphaned; /* RCU cbs orphaned by dying CPU */
+ unsigned long n_cbs_adopted; /* RCU cbs adopted from dying CPU */
unsigned long n_force_qs_snap;
/* did other CPU force QS recently? */
long blimit; /* Upper limit on a processed batch */
@@ -309,15 +309,7 @@ struct rcu_state {
/* End of fields guarded by root rcu_node's lock. */
raw_spinlock_t onofflock; /* exclude on/offline and */
- /* starting new GP. Also */
- /* protects the following */
- /* orphan_cbs fields. */
- struct rcu_head *orphan_cbs_list; /* list of rcu_head structs */
- /* orphaned by all CPUs in */
- /* a given leaf rcu_node */
- /* going offline. */
- struct rcu_head **orphan_cbs_tail; /* And tail pointer. */
- long orphan_qlen; /* Number of orphaned cbs. */
+ /* starting new GP. */
raw_spinlock_t fqslock; /* Only one task forcing */
/* quiescent states. */
unsigned long jiffies_force_qs; /* Time at which to invoke */
@@ -390,7 +382,7 @@ static void rcu_report_exp_rnp(struct rcu_state *rsp, struct rcu_node *rnp);
static int rcu_preempt_pending(int cpu);
static int rcu_preempt_needs_cpu(int cpu);
static void __cpuinit rcu_preempt_init_percpu_data(int cpu);
-static void rcu_preempt_send_cbs_to_orphanage(void);
+static void rcu_preempt_send_cbs_to_online(void);
static void __init __rcu_init_preempt(void);
static void rcu_needs_cpu_flush(void);
diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
index 71a4147..0e75d60 100644
--- a/kernel/rcutree_plugin.h
+++ b/kernel/rcutree_plugin.h
@@ -773,11 +773,11 @@ static void __cpuinit rcu_preempt_init_percpu_data(int cpu)
}
/*
- * Move preemptable RCU's callbacks to ->orphan_cbs_list.
+ * Move preemptable DYING RCU's callbacks to other online CPU.
*/
-static void rcu_preempt_send_cbs_to_orphanage(void)
+static void rcu_preempt_send_cbs_to_online(void)
{
- rcu_send_cbs_to_orphanage(&rcu_preempt_state);
+ rcu_send_cbs_to_online(&rcu_preempt_state);
}
/*
@@ -1001,7 +1001,7 @@ static void __cpuinit rcu_preempt_init_percpu_data(int cpu)
/*
* Because there is no preemptable RCU, there are no callbacks to move.
*/
-static void rcu_preempt_send_cbs_to_orphanage(void)
+static void rcu_preempt_send_cbs_to_online(void)
{
}
diff --git a/kernel/rcutree_trace.c b/kernel/rcutree_trace.c
index d15430b..cbead39 100644
--- a/kernel/rcutree_trace.c
+++ b/kernel/rcutree_trace.c
@@ -166,13 +166,13 @@ static void print_one_rcu_state(struct seq_file *m, struct rcu_state *rsp)
gpnum = rsp->gpnum;
seq_printf(m, "c=%lu g=%lu s=%d jfq=%ld j=%x "
- "nfqs=%lu/nfqsng=%lu(%lu) fqlh=%lu oqlen=%ld\n",
+ "nfqs=%lu/nfqsng=%lu(%lu) fqlh=%lu\n",
rsp->completed, gpnum, rsp->signaled,
(long)(rsp->jiffies_force_qs - jiffies),
(int)(jiffies & 0xffff),
rsp->n_force_qs, rsp->n_force_qs_ngp,
rsp->n_force_qs - rsp->n_force_qs_ngp,
- rsp->n_force_qs_lh, rsp->orphan_qlen);
+ rsp->n_force_qs_lh);
for (rnp = &rsp->node[0]; rnp - &rsp->node[0] < NUM_RCU_NODES; rnp++) {
if (rnp->level != level) {
seq_puts(m, "\n");
^ permalink raw reply related
* Re: [PATCH v2][memcg+dirtylimit] Fix overwriting global vm dirty limit setting by memcg (Re: [PATCH v3 00/11] memcg: per cgroup dirty page accounting
From: Daisuke Nishimura @ 2010-10-20 6:09 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: Greg Thelen, Andrew Morton, linux-kernel, linux-mm, containers,
Andrea Righi, Balbir Singh, Minchan Kim, Ciju Rajan K,
David Rientjes, Daisuke Nishimura
In-Reply-To: <20101020140255.5b8afb63.kamezawa.hiroyu@jp.fujitsu.com>
On Wed, 20 Oct 2010 14:02:55 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> Fixed one here.
> ==
> From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
>
> Now, at calculating dirty limit, vm_dirty_param() is called.
> This function returns dirty-limit related parameters considering
> memory cgroup settings.
>
> Now, assume that vm_dirty_bytes=100M (global dirty limit) and
> memory cgroup has 1G of pages and 40 dirty_ratio, dirtyable memory is
> 500MB.
>
> In this case, global_dirty_limits will consider dirty_limt as
> 500 *0.4 = 200MB. This is bad...memory cgroup is not back door.
>
> This patch limits the return value of vm_dirty_param() considring
> global settings.
>
> Changelog:
> - fixed an argument "mem" int to u64
> - fixed to use global available memory to cap memcg's value.
>
> Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Acked-by: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: Highlighting whitespace on removal with git diff
From: Junio C Hamano @ 2010-10-20 6:10 UTC (permalink / raw)
To: Kevin Ballard; +Cc: Stonky Fandango, git
In-Reply-To: <D058D986-2A83-4979-A461-F7CB34EF9448@sb.org>
Kevin Ballard <kevin@sb.org> writes:
> The highlight isn't telling you what changed on the line. It's telling
> you that this added line has trailing whitespace, and your
> core.whitespace config value is set such that this is considered an
> error.
>
> -Kevin Ballard
Which means that, in order to check for a whitespace error you removed in
your change, you can give "-R" (reverse) option to your "git diff".
^ permalink raw reply
* [U-Boot] [PATCH 1/1] MX5: Unable to get ip address when using dhcp
From: Jason Liu @ 2010-10-20 6:11 UTC (permalink / raw)
To: u-boot
Can't get IP address with dhcp due to the dhcp server not
allow the empty param list request under some network env
Add the advanced DHCP options to fix this issue:
CONFIG_BOOTP_SUBNETMASK
CONFIG_BOOTP_GATEWAY
CONFIG_BOOTP_DNS
Signed-off-by: Jason Liu <r64343@freescale.com>
---
include/configs/mx51evk.h | 4 ++++
include/configs/vision2.h | 4 ++++
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/include/configs/mx51evk.h b/include/configs/mx51evk.h
index 291404c..b1f673d 100644
--- a/include/configs/mx51evk.h
+++ b/include/configs/mx51evk.h
@@ -105,6 +105,10 @@
#define CONFIG_CMD_DHCP
#define CONFIG_CMD_MII
#define CONFIG_CMD_NET
+#define CONFIG_BOOTP_SUBNETMASK
+#define CONFIG_BOOTP_GATEWAY
+#define CONFIG_BOOTP_DNS
+
/* allow to overwrite serial and ethaddr */
#define CONFIG_ENV_OVERWRITE
diff --git a/include/configs/vision2.h b/include/configs/vision2.h
index a2ecbe5..7fdf17f 100644
--- a/include/configs/vision2.h
+++ b/include/configs/vision2.h
@@ -127,6 +127,10 @@
#define CONFIG_CMD_PING
#define CONFIG_CMD_MII
#define CONFIG_CMD_NET
+#define CONFIG_BOOTP_SUBNETMASK
+#define CONFIG_BOOTP_GATEWAY
+#define CONFIG_BOOTP_DNS
+
/* allow to overwrite serial and ethaddr */
#define CONFIG_ENV_OVERWRITE
--
1.7.0.4
^ permalink raw reply related
* Interesting possible XFS crash condition
From: Shawn Usry @ 2010-10-20 6:13 UTC (permalink / raw)
To: xfs
Hi List -
First off, thanks for the great filesystem. Thus far it's been an
excellent performer for my needs both professionally and personally.
I have a situation/environment that is producing a kernel crash, that
may be XFS related. A colleague suggested I post to this list as there
may be some interest in reproducing it.
Environment (current):
Fedora core 13 (kernel 2.6.34.7-56.fc13.i686)
xfsprogs-3.1.1-7.fc13.i686
RAID5 Controller: 3ware 9550-SXU-8LP 8-port sata controller, 64-bit PCI-X.
XFS filesystem in question is on a RAID 5 array on this controller, made
of up 4 identical disks, 1.5TB each, 64k stripe (block device = /dev/sdb)
The setup:
ORIGINALLY, this was a 3-disk RAID5. Created the XFS filesystem with:
--> mkfs -t xfs /dev/sdb
All was well in use to this point.
Next, I ADDED a 4th disk to the array, and expanded the array in place;
and operation supported by this RAID device.
New usable size = 4.5T
Once completed, I grew the XFS filesystem with xfs_growxfs to expand
into the full size of the new array.
Again, all was well, for about a week of normal use - fairly heavy
copy/read/write operations on a regular basis.
Then, without any changes or warning (that I was aware of at least), the
machine started crashing/kernel panic anytime I accessed (read/write)
MOST of the files in the filesystem. Some files could be accessed
without a problem. In general though any kind of high I/O (copying a
file (not moving) to the same device, copying to another block
device/disk, reading it across the network, etc) now causes the
condition, observed by access occurring normally for the first few MB
(this seems to vary in value) and then the system locking up completely.
Most of the time, the system becomes unresponsive and must be rebooted
to gain access again. In some cases though, system access will return,
on a limited / choppy basis and messages like "card reset" will appear
in the message log.
The latter statement and observations lead me to believe that perhaps
this was simply a yucky controller that was failing under heavy I/O.
However, several other tests/observations leave me wondering if it may
be a corrupt filesystem in some way, that is not being detected by
xfs_repair.
Tests / Observations:
1. Mounted, or Unmounted, I can "dd" the block device array (/dev/sdb)
all day long without a problem:
--> dd if=/dev/sdb of=/dev/null bs=(varied tests) result: end to end
no problem
--> dd if=/dev/sdb of=/tmp/test.file bs=(varies) result: no problem
(as long as test.file space permits..)
2. I can CREATE arbitrary NEW files onto the filesystem, and copy them
/read them OFF the device, such as a disk-to-otherdisk,
disk-to-samedisk, copy across the network, etc, read them, delete, them
- NO CRASH.
--> dd if=/dev/zero of=/myblkdevice/test.file bs=1M count=1024 (create
an arbitrary 1GB file). All normal.
3. Copying / Reading existing files (at least, that existed at the time
I grew the array) seems to trigger the system crash. Copying/reading
said NEW files (i.e., #2 above) does NOT trigger the crash.
4. Copying EXISTING files from other servers / locations on the
network, or other disks, to the device triggers the crash (i.e., would
be a NEW file being copied to the array, but not created ON the array).
5. Unmounted, xfs_repair -n /dev/sdb ---> finds no issues
6. Unmounted, xfs_repair /dev/sdb ---> finds no issues, performs no
changes.
Other Notes:
1. I did recently learn of the create-time and mount-time options
sunit/swidth for optimizing performance. Setting these had no effect
on this issue.
2. SOME files behave perfectly normal. I can copy them, read them, etc
without a problem. But for the MOST part, MOST files, and MOST all file
operations seem to trigger the crash, though
3. Limited information shown in what I've been able to capture in the
kernel crash. Nothing really specific or repeatable (different message
each time) - some instances to the term "atomic" and "xfs" - other times
"irq" related.
4. In general the crash seems to happen when I either:
a. Attempt to do any reads of files larger than 100 MB or so
(small, single operations don't seem to have an effect, but strings of
small operations (unzipping a dir of files, for example) does).
b. Attempt to move or copy any data to the filesystem that didn't
ORIGINATE on the filesystem.
Questions:
1. Is is possible that my raid-expansion on the 3ware board brought on
some kind of corruption? Might not xfs_repair detect this if so?
2. Are there any thoughts / patches / commands / debug options I might
try to resolve this?
3. Is this more likely a problem with the 3ware controller + XFS
combination?
The only recourse I've thought of is to completely wipe the array and
start from scratch with a fresh 4-disk array, and XFS filesystem
creation, then copy data back to it.
I can't leave this device in place in an unusable state very long - I
just thought this list might be interested in the conditions. Any
suggestions or thoughts would be greatly appreciated. Resolving this
would save me a good deal of time.
Shawn
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* Re: [PATCH -v3 5/6] x86, NMI, treat unknown NMI as hardware error
From: Huang Ying @ 2010-10-20 6:12 UTC (permalink / raw)
To: Don Zickus
Cc: Ingo Molnar, H. Peter Anvin, linux-kernel@vger.kernel.org,
Andi Kleen, Robert Richter
In-Reply-To: <20101011212006.GB23882@redhat.com>
Hi, Don,
On Tue, 2010-10-12 at 05:20 +0800, Don Zickus wrote:
> > @@ -366,6 +368,15 @@ unknown_nmi_error(unsigned char reason,
> > if (notify_die(DIE_NMIUNKNOWN, "nmi", regs, reason, 2, SIGINT) ==
> > NOTIFY_STOP)
> > return;
> > + /*
> > + * On some platforms, hardware errors may be notified via
> > + * unknown NMI
> > + */
> > + if (unknown_nmi_as_hwerr)
> > + panic(
> > + "NMI for hardware error without error record: Not continuing\n"
> > + "Please check BIOS/BMC log for further information.");
> > +
> > #ifdef CONFIG_MCA
> > /*
> > * Might actually be able to figure out what the guilty party
>
> The only quirk I have left is the above piece, which is basically a
> philosophy difference with Robert and myself. Where we believe it should
> be on the die_chain and Andi and yourself would like to see it explicitly
> called out.
After some more thought, I found this is different from DIE_NMI and
DIE_NMI_IPI case. I think the code added is for general unknown NMI
processing instead of a device driver. What we do is not to add special
processing for some devices, but treat unknown NMI as hardware error
notification in general and use a white list to deal with broken
hardware and stone age machine. Do you agree?
If so, it should not be turned into a notifier block unless you want to
turn all general unknown NMI processing code into a notifier block.
Best Regards,
Huang Ying
^ permalink raw reply
* [PATCH 0/3] Add OMAP hardware spinlock misc driver
From: Ohad Ben-Cohen @ 2010-10-20 6:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1287531090.9245.139.camel@c-dwalke-linux.qualcomm.com>
On Wed, Oct 20, 2010 at 1:31 AM, Daniel Walker <dwalker@codeaurora.org> wrote:
> On Mon, 2010-10-18 at 09:44 +0200, Ohad Ben-Cohen wrote:
>> OMAP4 introduces a Spinlock hardware module, which provides hardware
>> assistance for synchronization and mutual exclusion between heterogeneous
>> processors and those not operating under a single, shared operating system
>> (e.g. OMAP4 has dual Cortex-A9, dual Cortex-M3 and a C64x+ DSP).
>>
>> The intention of this hardware module is to allow remote processors,
>> that have no alternative mechanism to accomplish synchronization and mutual
>> exclusion operations, to share resources (such as memory and/or any other
>> hardware resource).
>>
>> This patchset adds a new misc driver for this OMAP hwspinlock module.
>
> Does this code interface with some hardware unit (other than the other
> processors) to accomplish this locking ?
Yes, it's a special-purpose hardware peripheral.
> The reason I ask is because MSM has similar code, and from what I can
> tell the MSM version has some structures in memory but that's all. It
> just operates on the structures in memory.
That's interesting.
We did have thoughts of making this a generic framework, in the hope
that it would be useful for other vendors too, but we didn't find
additional users.
> It might be worth looking over the two implementation so we aren't both
> remaking the wheel.
Indeed. Where is that MSM code ?
Thanks,
Ohad.
^ permalink raw reply
* Re: [PATCH 0/3] Add OMAP hardware spinlock misc driver
From: Ohad Ben-Cohen @ 2010-10-20 6:13 UTC (permalink / raw)
To: Daniel Walker
Cc: linux-kernel, linux-arm-kernel, akpm, Greg KH, Tony Lindgren,
Benoit Cousson, Grant Likely, Hari Kanigeri, Suman Anna, mattw
In-Reply-To: <1287531090.9245.139.camel@c-dwalke-linux.qualcomm.com>
On Wed, Oct 20, 2010 at 1:31 AM, Daniel Walker <dwalker@codeaurora.org> wrote:
> On Mon, 2010-10-18 at 09:44 +0200, Ohad Ben-Cohen wrote:
>> OMAP4 introduces a Spinlock hardware module, which provides hardware
>> assistance for synchronization and mutual exclusion between heterogeneous
>> processors and those not operating under a single, shared operating system
>> (e.g. OMAP4 has dual Cortex-A9, dual Cortex-M3 and a C64x+ DSP).
>>
>> The intention of this hardware module is to allow remote processors,
>> that have no alternative mechanism to accomplish synchronization and mutual
>> exclusion operations, to share resources (such as memory and/or any other
>> hardware resource).
>>
>> This patchset adds a new misc driver for this OMAP hwspinlock module.
>
> Does this code interface with some hardware unit (other than the other
> processors) to accomplish this locking ?
Yes, it's a special-purpose hardware peripheral.
> The reason I ask is because MSM has similar code, and from what I can
> tell the MSM version has some structures in memory but that's all. It
> just operates on the structures in memory.
That's interesting.
We did have thoughts of making this a generic framework, in the hope
that it would be useful for other vendors too, but we didn't find
additional users.
> It might be worth looking over the two implementation so we aren't both
> remaking the wheel.
Indeed. Where is that MSM code ?
Thanks,
Ohad.
^ permalink raw reply
* Re: [PATCH] diff: handle lines containing only whitespace better
From: Junio C Hamano @ 2010-10-20 6:16 UTC (permalink / raw)
To: Kevin Ballard; +Cc: git
In-Reply-To: <1287549978-54280-1-git-send-email-kevin@sb.org>
Hmm, tests?
^ permalink raw reply
* [U-Boot] [PATCH v3] 85xx: Add support for not releasing secondary cores via 'mp_holdoff'
From: Kumar Gala @ 2010-10-20 6:16 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1285867336-24188-1-git-send-email-ptyser@xes-inc.com>
On Sep 30, 2010, at 12:22 PM, Peter Tyser wrote:
> From: Aaron Sierra <asierra@xes-inc.com>
>
> Some OSes require that secondary cores not be initialized when they
> are booted (eg VxWorks). By default when U-Boot is compiled with the
> CONFIG_MP option all secondary cores are brought out of reset and held
> in spinloops. Setting the "mp_holdoff" environment variable to 'yes'
> or '1' will cause U-Boot to leave secondary cores in their default
> state.
>
> Signed-off-by: Aaron Sierra <asierra@xes-inc.com>
> Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
> ---
> Changes since v1:
> - Update 'enable-method' in dtb appropriately
> - Don't set cpu-release-addr if spin-table isn't used
> - Add hold_cores_in_reset() function with more intelligent mp_holdoff
> environment variable checking
>
> Changes since v2:
> - Fixed enable-method inconsistency pointed out by Scott
>
> arch/powerpc/cpu/mpc85xx/fdt.c | 22 +++++++++++++++++++---
> arch/powerpc/cpu/mpc85xx/mp.c | 31 +++++++++++++++++++++++++++++++
> arch/powerpc/cpu/mpc85xx/mp.h | 1 +
> 3 files changed, 51 insertions(+), 3 deletions(-)
applied to 85xx
- k
^ permalink raw reply
* Re: [Bridge] 2.6.36-rc7: net/bridge causes temporary network I/O lockups [2]
From: Herbert Xu @ 2010-10-20 6:16 UTC (permalink / raw)
To: Patrick Ringl; +Cc: netdev, bridge, linux-kernel
In-Reply-To: <4CBCB014.9080108@freenet.de>
On Mon, Oct 18, 2010 at 10:37:40PM +0200, Patrick Ringl wrote:
>
> Anything else I could possibly provide? :-)
Yes, testing :)
First of all I'd like to rule out (or in) the IPv6 query code,
which is clearly generating a bogus packet (wrong payload_len).
So can you apply this patch and see if it makes the problem
go away? Please take packet dumps so we know that the IPv6 query
is no longer being sent.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index eb5b256..66f39d7 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -832,11 +832,6 @@ static void br_multicast_send_query(struct net_bridge *br,
br_group.proto = htons(ETH_P_IP);
__br_multicast_send_query(br, port, &br_group);
-#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
- br_group.proto = htons(ETH_P_IPV6);
- __br_multicast_send_query(br, port, &br_group);
-#endif
-
time = jiffies;
time += sent < br->multicast_startup_query_count ?
br->multicast_startup_query_interval :
^ permalink raw reply related
* Re: 2.6.36-rc7: net/bridge causes temporary network I/O lockups [2]
From: Herbert Xu @ 2010-10-20 6:16 UTC (permalink / raw)
To: Patrick Ringl; +Cc: netdev, linux-kernel, bridge
In-Reply-To: <4CBCB014.9080108@freenet.de>
On Mon, Oct 18, 2010 at 10:37:40PM +0200, Patrick Ringl wrote:
>
> Anything else I could possibly provide? :-)
Yes, testing :)
First of all I'd like to rule out (or in) the IPv6 query code,
which is clearly generating a bogus packet (wrong payload_len).
So can you apply this patch and see if it makes the problem
go away? Please take packet dumps so we know that the IPv6 query
is no longer being sent.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index eb5b256..66f39d7 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -832,11 +832,6 @@ static void br_multicast_send_query(struct net_bridge *br,
br_group.proto = htons(ETH_P_IP);
__br_multicast_send_query(br, port, &br_group);
-#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
- br_group.proto = htons(ETH_P_IPV6);
- __br_multicast_send_query(br, port, &br_group);
-#endif
-
time = jiffies;
time += sent < br->multicast_startup_query_count ?
br->multicast_startup_query_interval :
^ permalink raw reply related
* Re: 2.6.36-rc7: net/bridge causes temporary network I/O lockups [2]
From: Herbert Xu @ 2010-10-20 6:16 UTC (permalink / raw)
To: Patrick Ringl; +Cc: netdev, linux-kernel, bridge
In-Reply-To: <4CBCB014.9080108@freenet.de>
On Mon, Oct 18, 2010 at 10:37:40PM +0200, Patrick Ringl wrote:
>
> Anything else I could possibly provide? :-)
Yes, testing :)
First of all I'd like to rule out (or in) the IPv6 query code,
which is clearly generating a bogus packet (wrong payload_len).
So can you apply this patch and see if it makes the problem
go away? Please take packet dumps so we know that the IPv6 query
is no longer being sent.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index eb5b256..66f39d7 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -832,11 +832,6 @@ static void br_multicast_send_query(struct net_bridge *br,
br_group.proto = htons(ETH_P_IP);
__br_multicast_send_query(br, port, &br_group);
-#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
- br_group.proto = htons(ETH_P_IPV6);
- __br_multicast_send_query(br, port, &br_group);
-#endif
-
time = jiffies;
time += sent < br->multicast_startup_query_count ?
br->multicast_startup_query_interval :
^ permalink raw reply related
* Re: [PATCH v2][memcg+dirtylimit] Fix overwriting global vm dirty limit setting by memcg (Re: [PATCH v3 00/11] memcg: per cgroup dirty page accounting
From: Daisuke Nishimura @ 2010-10-20 6:09 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: Greg Thelen, Andrew Morton, linux-kernel, linux-mm, containers,
Andrea Righi, Balbir Singh, Minchan Kim, Ciju Rajan K,
David Rientjes, Daisuke Nishimura
In-Reply-To: <20101020140255.5b8afb63.kamezawa.hiroyu@jp.fujitsu.com>
On Wed, 20 Oct 2010 14:02:55 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> Fixed one here.
> ==
> From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
>
> Now, at calculating dirty limit, vm_dirty_param() is called.
> This function returns dirty-limit related parameters considering
> memory cgroup settings.
>
> Now, assume that vm_dirty_bytes=100M (global dirty limit) and
> memory cgroup has 1G of pages and 40 dirty_ratio, dirtyable memory is
> 500MB.
>
> In this case, global_dirty_limits will consider dirty_limt as
> 500 *0.4 = 200MB. This is bad...memory cgroup is not back door.
>
> This patch limits the return value of vm_dirty_param() considring
> global settings.
>
> Changelog:
> - fixed an argument "mem" int to u64
> - fixed to use global available memory to cap memcg's value.
>
> Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Acked-by: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
^ 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.