* Re: [patch 07/28] posix-timers: Convert clock_nanosleep_restart to clockid_to_kclock()
From: Thomas Gleixner @ 2011-02-01 21:08 UTC (permalink / raw)
To: John Stultz; +Cc: LKML, Richard Cochran, Ingo Molnar, Peter Zijlstra
In-Reply-To: <alpine.LFD.2.00.1102012145500.31804@localhost6.localdomain6>
On Tue, 1 Feb 2011, Thomas Gleixner wrote:
> On Tue, 1 Feb 2011, John Stultz wrote:
>
> > On Tue, 2011-02-01 at 13:51 +0000, Thomas Gleixner wrote:
> > > plain text document attachment
> > > (posix-timers-convert-nanosleep-restart.patch)
> > > Use the new kclock decoding function in clock_nanosleep_restart. No
> > > need to check kclock here as the restart block always contains a valid
> > > clockid. If not, we are in serious trouble anyway.
> > >
> > > Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> > > Cc: John Stultz <john.stultz@linaro.org>
> > > Cc: Richard Cochran <richard.cochran@omicron.at>
> >
> > One nit.
> >
> > > -long
> > > -clock_nanosleep_restart(struct restart_block *restart_block)
> > > +long clock_nanosleep_restart(struct restart_block *restart_block)
> > > {
> > > clockid_t which_clock = restart_block->arg0;
> > > + struct k_clock *kc = clockid_to_kclock(which_clock);
> > >
> > > - return CLOCK_DISPATCH(which_clock, nsleep_restart,
> > > - (restart_block));
> > > + return kc->nsleep_restart(restart_block);
> > > }
> >
> >
> > Should you be checking if kc is null before dereferencing? Or am I being
> > overly paranoid?
>
> See changelog. If we get a corrupted restart_block then checking kc is
> probably the least of our worries.
Ok, I'll add the checks for nsleep_restart and timer_get/set/del, but
I make them a WARN_ON_ONCE() as this is serious data corruption in the
kernel.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH] e2fsprogs: Fix how we treat user-spcified filesystem size
From: Lukas Czerner @ 2011-02-01 21:08 UTC (permalink / raw)
To: Andreas Dilger; +Cc: Lukas Czerner, linux-ext4, tytso
In-Reply-To: <140BFB14-31E6-4E76-B1DA-5CD8F54FDD5B@dilger.ca>
On Tue, 1 Feb 2011, Andreas Dilger wrote:
> On 2011-02-01, at 12:18, Lukas Czerner wrote:
> > +Optionally, the
> > +.I filesystem-size
> > +parameter may be suffixed by one of the following the units
> > +designators: 'b', 's', 'K', 'M', or 'G',
> > +for blocks count, 512 byte sectors, kilobytes, megabytes, or gigabytes,
> > +respectively.
>
> My reading of parse_num_blocks() shows that 'T' is also accepted as a suffix for terabytes, which I was otherwise going to suggest be added, since this is the normal size for filesystems today. It might be worthwhile _briefly_ mentioning here that these are binary/power-of-two values and not decimal values, instead of the rant further below.
The rant below was ripped of resize2fs man page, but I agree.
>
> Minor technical nit - the proper metric value is lower-case 'k' for kilo, though the upper-case 'M', 'G', and 'T' are correct for mega-, giga-, and terabytes.
You're right, I completely missed 'T', will fix that. Regarding the
minor technical nit, I know that, but I have just ripped that from
resize2fs man page without really paying attention. Anyway thanks for
corrections I'll fix it as well.
>
> > diff --git a/resize/resize2fs.8.in b/resize/resize2fs.8.in
> > --- a/resize/resize2fs.8.in
> > +++ b/resize/resize2fs.8.in
> > @@ -38,13 +38,13 @@ The
> > +designators: 'b', 's', 'K', 'M', or 'G',
> > +for blocks count, 512 byte sectors, kilobytes, megabytes, or gigabytes,
> > +respectively. The
>
> Similarly, this also supports 'T' for terabytes, since it uses the same parse_num_blocks() function.
>
> Cheers, Andreas
>
Thanks!
-Lukas
^ permalink raw reply
* [Bug 27912] Set 'err' in ext4_init_fs() if kset_create_and_add() fails
From: bugzilla-daemon @ 2011-02-01 21:07 UTC (permalink / raw)
To: linux-ext4
In-Reply-To: <bug-27912-13602@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=27912
--- Comment #3 from Eugene A. Shatokhin <dame_eugene@mail.ru> 2011-02-01 21:07:13 ---
I have just built and tested the patched ext4.ko module. Yes, the problem with
/sys/fs/ext4 is now fixed as it was expected.
Obviously, the patch does not fix that problem with 'err' that I reported. So
the patch probably needs to be changed a little.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [PATCH][SVM] Fix 32bit Windows guest VMs save/restore
From: Wei Huang @ 2011-02-01 21:06 UTC (permalink / raw)
To: Keir Fraser; +Cc: xen-devel@lists.xensource.com
In-Reply-To: <C96D7F89.16623%keir@xen.org>
[-- Attachment #1: Type: text/plain, Size: 680 bytes --]
How does this one look? It should address your concern about duplicating
data in both vcpu and vmcb. I have tested it with both 32bit and 64bit
Windows successfully.
-Wei
=================
Fix 32bit guest VM save/restore issues associated with SYSENTER MSRs on
AMD platforms.
This patch turn-on SYSENTER MSRs interception for 32bit guest VMs on AMD
CPUs. With it, hvm_svm.guest_sysenter_xx fields always contain the
canonical version of SYSENTER MSRs and are used in guest save/restore.
The data fields in VMCB save area are updated as necessary.
Reported-by: James Harper <james.harper@bendigoit.com.au>
Signed-off-by: Wei Huang <wei.huang2@amd.com>
=================
[-- Attachment #2: amd_fix_32bit_save_restore.txt --]
[-- Type: text/plain, Size: 2551 bytes --]
diff -r d972e89797f1 xen/arch/x86/hvm/svm/svm.c
--- a/xen/arch/x86/hvm/svm/svm.c Mon Jan 31 23:57:19 2011 -0600
+++ b/xen/arch/x86/hvm/svm/svm.c Tue Feb 01 15:03:15 2011 -0600
@@ -224,10 +224,11 @@
hvm_update_guest_cr(v, 2);
hvm_update_guest_cr(v, 4);
- v->arch.hvm_svm.guest_sysenter_cs = c->sysenter_cs;
- v->arch.hvm_svm.guest_sysenter_esp = c->sysenter_esp;
- v->arch.hvm_svm.guest_sysenter_eip = c->sysenter_eip;
-
+ /* load sysenter MSRs into VMCB save area and VCPU fields */
+ vmcb->sysenter_cs = v->arch.hvm_svm.guest_sysenter_cs = c->sysenter_cs;
+ vmcb->sysenter_esp = v->arch.hvm_svm.guest_sysenter_esp = c->sysenter_esp;
+ vmcb->sysenter_eip = v->arch.hvm_svm.guest_sysenter_eip = c->sysenter_eip;
+
if ( paging_mode_hap(v->domain) )
{
vmcb_set_np_enable(vmcb, 1);
@@ -433,14 +434,6 @@
if ( lma )
new_efer |= EFER_LME;
vmcb_set_efer(vmcb, new_efer);
-
- /*
- * In legacy mode (EFER.LMA=0) we natively support SYSENTER/SYSEXIT with
- * no need for MSR intercepts. When EFER.LMA=1 we must trap and emulate.
- */
- svm_intercept_msr(v, MSR_IA32_SYSENTER_CS, lma);
- svm_intercept_msr(v, MSR_IA32_SYSENTER_ESP, lma);
- svm_intercept_msr(v, MSR_IA32_SYSENTER_EIP, lma);
}
static void svm_sync_vmcb(struct vcpu *v)
@@ -1142,6 +1135,21 @@
{
struct vcpu *v = current;
struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
+ int sync = 0;
+
+ switch ( msr )
+ {
+ case MSR_IA32_SYSENTER_CS:
+ case MSR_IA32_SYSENTER_ESP:
+ case MSR_IA32_SYSENTER_EIP:
+ sync = 1;
+ break;
+ default:
+ break;
+ }
+
+ if ( sync )
+ svm_sync_vmcb(v);
switch ( msr )
{
@@ -1149,13 +1157,13 @@
goto gpf;
case MSR_IA32_SYSENTER_CS:
- v->arch.hvm_svm.guest_sysenter_cs = msr_content;
+ vmcb->sysenter_cs = v->arch.hvm_svm.guest_sysenter_cs = msr_content;
break;
case MSR_IA32_SYSENTER_ESP:
- v->arch.hvm_svm.guest_sysenter_esp = msr_content;
+ vmcb->sysenter_esp = v->arch.hvm_svm.guest_sysenter_esp = msr_content;
break;
case MSR_IA32_SYSENTER_EIP:
- v->arch.hvm_svm.guest_sysenter_eip = msr_content;
+ vmcb->sysenter_eip = v->arch.hvm_svm.guest_sysenter_eip = msr_content;
break;
case MSR_IA32_DEBUGCTLMSR:
@@ -1213,6 +1221,10 @@
wrmsr_hypervisor_regs(msr, msr_content);
break;
}
+
+ if ( sync )
+ svm_vmload(vmcb);
+
return X86EMUL_OKAY;
gpf:
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* [refpolicy] [PATCH] Add TSS Core Services (TCS) daemon (tcsd) policy
From: Daniel J Walsh @ 2011-02-01 21:05 UTC (permalink / raw)
To: refpolicy
In-Reply-To: <1296501420.26427.46.camel@moss-pluto>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Our version of tcsd policy
Steve I suppose we are going to need this in RHEL6.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk1IdbcACgkQrlYvE4MpobMaCwCgxr5qZHG1GzFOWwRXvWcex4jW
wdMAn2zU5VwffzfXlkzYM07bOliEw/xS
=4oVi
-----END PGP SIGNATURE-----
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: tcsd.patch
Url: http://oss.tresys.com/pipermail/refpolicy/attachments/20110201/34d32f08/attachment-0001.pl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tcsd.patch.sig
Type: application/pgp-signature
Size: 72 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110201/34d32f08/attachment-0001.bin
^ permalink raw reply
* iMX31 MBX registers Porting problem
From: Chris @ 2011-02-01 21:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTin4fPo6pKWLCqb+BXNS-hDrWPLEK7QQErbuq15C@mail.gmail.com>
> ?I have gone the extra distance in turning off support in the working kernel
> 2.6.19.2, I have removed nearly everything. I am down to the gpio_port
>
^ permalink raw reply
* [Bug 33172] [r600g] ingame rendering broken (black screen) in ut2003
From: bugzilla-daemon @ 2011-02-01 21:04 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-33172-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=33172
Tobias Jakobi <liquid.acid@gmx.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #6 from Tobias Jakobi <liquid.acid@gmx.net> 2011-02-01 13:04:35 PST ---
Looks like the problem got fixed by the recent changes to the vertex buffer
upload code. Both ut2003 and ut2004 now work flawlessly.
Thanks Marek!
--
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
* Re: What's the typical RAID10 setup?
From: Roberto Spadim @ 2011-02-01 21:04 UTC (permalink / raw)
To: Keld Jørn Simonsen; +Cc: David Brown, linux-raid
In-Reply-To: <AANLkTiksG6oJMdJ=z3ZELk=_2FWGRWVVhHUvrBPa2+J1@mail.gmail.com>
the problem for benchmark on linux (mdadm) raid implementation (raid1
vs raid0) is:
raid1 read balance(closest head) is diferent from raid0 read
balance(stripe) algorithm
it´s good but can´t be as fast as raid0 for read intensive (sequential)
the problem of closest head algorithm is it can´t paralelize reads
like raid0 paralelize
2011/2/1 Roberto Spadim <roberto@spadim.com.br>:
>> For sequential reading, this is not true. For random reading and
>> writing I agree with you in theory, but benchmarks show that it is not
>> so, at least for Linux RAID, viz the above URL.
>
> i agree with you, since linux algorith for raid1 is closest head, not
> round robin or time based
>
> there´s some patch on internet (google it: round robin raid1 linux)
> for roundrobin, but none for time based =(
> it´s a point of optimization of today raid1 algorithm
>
> round robin (may be at this mail list)
> http://www.spinics.net/lists/raid/msg30003.html
>
> 2011/2/1 Keld Jørn Simonsen <keld@keldix.com>:
>> On Tue, Feb 01, 2011 at 05:02:46PM +0100, Keld Jørn Simonsen wrote:
>>> On Tue, Feb 01, 2011 at 11:01:33AM +0100, David Brown wrote:
>>> > On 31/01/2011 23:52, Keld Jørn Simonsen wrote:
>>> > >raid1+0 and Linux MD raid10 are similar, but significantly different
>>> > >in a number of ways. Linux MD raid10 can run on only 2 drives.
>>> > >Linux raid10,f2 has almost RAID0 striping performance in sequential read.
>>> > >You can have an odd number of drives in raid10.
>>> > >And you can have as many copies as you like in raid10,
>>> > >
>>> >
>>> > You can make raid10,f2 functionality from raid1+0 by using partitions.
>>> > For example, to get a raid10,f2 equivalent on two drives, partition them
>>> > into equal halves. Then make md0 a raid1 mirror of sda1 and sdb2, and
>>> > md1 a raid1 mirror of sdb1 and sda2. Finally, make md2 a raid0 stripe
>>> > set of md0 and md1.
>>>
>>> I don't think you get the striping performance of raid10,f2 with this
>>> layout. And that is one of the main advantages of raid10,f2 layout.
>>> Have you tried it out?
>>>
>>> As far as I can see the layout of blocks are not alternating between the
>>> disks. You have one raid1 of sda1 and sdb2, there a file is allocated on
>>> blocks sequentially on sda1 and then mirrored on sdb2, where it is also
>>> sequentially allocated. That gives no striping.
>>
>> Well, maybe the RAID0 layer provides the adequate striping.
>> I am noy sure, but it looks like it could hold in theory.
>> One could try it out.
>>
>> One advantage of this scheme could be improved probability
>> When 2 drives fail, eg. in the case of a 4 drive array.
>> The probability of survival of a running system could then
>> be enhaced form 33 % to 66 %.
>>
>> One problem could be the choice of always the lowest block number, which
>> is secured in raid10,f2, but not in a raid0 over raid1 (or raid10,n2) scenario.
>>
>> best regards
>> keld
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
>
>
> --
> Roberto Spadim
> Spadim Technology / SPAEmpresarial
>
--
Roberto Spadim
Spadim Technology / SPAEmpresarial
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 2/2] compat: add support for kernel 2.6.38
From: Hauke Mehrtens @ 2011-02-01 21:04 UTC (permalink / raw)
To: mcgrof; +Cc: linux-wireless, Hauke Mehrtens
In-Reply-To: <1296594253-21273-1-git-send-email-hauke@hauke-m.de>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
include/linux/compat-2.6.38.h | 17 -----------------
include/linux/compat-2.6.39.h | 27 +++++++++++++++++++++++++++
include/linux/compat-2.6.h | 1 +
3 files changed, 28 insertions(+), 17 deletions(-)
create mode 100644 include/linux/compat-2.6.39.h
diff --git a/include/linux/compat-2.6.38.h b/include/linux/compat-2.6.38.h
index 0521156..004fe27 100644
--- a/include/linux/compat-2.6.38.h
+++ b/include/linux/compat-2.6.38.h
@@ -8,23 +8,6 @@
#include <linux/kernel.h>
#include <linux/skbuff.h>
-/*
- * This is not part of The 2.6.37 kernel yet but we
- * we use it to optimize the backport code we
- * need to implement. Instead of using ifdefs
- * to check what version of the check we use
- * we just replace all checks on current code
- * with this. I'll submit this upstream too, that
- * way all we'd have to do is to implement this
- * for older kernels, then we would not have to
- * edit the upstrema code for backport efforts.
- */
-#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,36))
-#define br_port_exists(dev) (dev->priv_flags & IFF_BRIDGE_PORT)
-#else
-#define br_port_exists(dev) (dev->br_port)
-#endif
-
/* rename member in struct mmc_host in include/linux/mmc/host.h */
#define max_segs max_hw_segs
diff --git a/include/linux/compat-2.6.39.h b/include/linux/compat-2.6.39.h
new file mode 100644
index 0000000..c0c98fd
--- /dev/null
+++ b/include/linux/compat-2.6.39.h
@@ -0,0 +1,27 @@
+#ifndef LINUX_26_39_COMPAT_H
+#define LINUX_26_39_COMPAT_H
+
+#include <linux/version.h>
+
+#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,39))
+
+/*
+ * This is not part of The 2.6.37 kernel yet but we
+ * we use it to optimize the backport code we
+ * need to implement. Instead of using ifdefs
+ * to check what version of the check we use
+ * we just replace all checks on current code
+ * with this. I'll submit this upstream too, that
+ * way all we'd have to do is to implement this
+ * for older kernels, then we would not have to
+ * edit the upstrema code for backport efforts.
+ */
+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,36))
+#define br_port_exists(dev) (dev->priv_flags & IFF_BRIDGE_PORT)
+#else
+#define br_port_exists(dev) (dev->br_port)
+#endif
+
+#endif /* (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,39)) */
+
+#endif /* LINUX_26_39_COMPAT_H */
diff --git a/include/linux/compat-2.6.h b/include/linux/compat-2.6.h
index 2706797..478f833 100644
--- a/include/linux/compat-2.6.h
+++ b/include/linux/compat-2.6.h
@@ -31,5 +31,6 @@
#include <linux/compat-2.6.36.h>
#include <linux/compat-2.6.37.h>
#include <linux/compat-2.6.38.h>
+#include <linux/compat-2.6.39.h>
#endif /* LINUX_26_COMPAT_H */
--
1.7.1
^ permalink raw reply related
* [PATCH 1/2] compat: backport alloc_ordered_workqueue
From: Hauke Mehrtens @ 2011-02-01 21:04 UTC (permalink / raw)
To: mcgrof; +Cc: linux-wireless, Hauke Mehrtens
This was moved from a patch in compat-wireless to this place.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
include/linux/compat-2.6.37.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/linux/compat-2.6.37.h b/include/linux/compat-2.6.37.h
index 502d2b1..e993f75 100644
--- a/include/linux/compat-2.6.37.h
+++ b/include/linux/compat-2.6.37.h
@@ -106,6 +106,8 @@ extern void compat_led_classdev_unregister(struct led_classdev *led_cdev);
extern void compat_led_brightness_set(struct led_classdev *led_cdev,
enum led_brightness brightness);
+#define alloc_ordered_workqueue(name, flags) create_singlethread_workqueue(name)
+
#endif /* (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,37)) */
#endif /* LINUX_26_37_COMPAT_H */
--
1.7.1
^ permalink raw reply related
* [Buildroot] [PATCH] Add cryptsetup package
From: Thomas Petazzoni @ 2011-02-01 21:04 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1296580718-4746-1-git-send-email-mort@bork.org>
Hello,
On Tue, 1 Feb 2011 12:18:38 -0500
Martin Hicks <mort@bork.org> wrote:
> +CRYPTSETUP_INSTALL_STAGING = NO
> +CRYPTSETUP_INSTALL_TARGET = YES
Those are not needed, this is the default.
> +#CRYPTSETUP_CONF_OPT = --BLAH
Not needed (but removed by your followup patch that should be merged
here).
> +CRYPTSETUP_DEPENDENCIES = lvm2 libgcrypt popt e2fsprogs
As done by your followup patch, if you have an e2fsprogs dependency
here, you should also have the dependency in the Config.in file.
Thanks!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [Buildroot] [PATCH] cryptsetup: select e2fsprogs for libuuid dependency
From: Thomas Petazzoni @ 2011-02-01 21:03 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1296585857-5491-1-git-send-email-mort@bork.org>
Hello Martin,
This patch should be merged in your previous cryptsetup patch. Could
you resend a single patch with those two patches merged ?
Thanks,
Thomas
On Tue, 1 Feb 2011 13:44:17 -0500
Martin Hicks <mort@bork.org> wrote:
> Signed-off-by: Martin Hicks <mort@bork.org>
> ---
> package/cryptsetup/Config.in | 1 +
> package/cryptsetup/cryptsetup.mk | 1 -
> 2 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/package/cryptsetup/Config.in b/package/cryptsetup/Config.in
> index 23c4afa..8b543cd 100644
> --- a/package/cryptsetup/Config.in
> +++ b/package/cryptsetup/Config.in
> @@ -3,6 +3,7 @@ config BR2_PACKAGE_CRYPTSETUP
> select BR2_PACKAGE_LIBGCRYPT
> select BR2_PACKAGE_POPT
> select BR2_PACKAGE_LVM2
> + select BR2_PACKAGE_E2FSPROGS
> help
> This tool helps manipulate dm-crypt and luks partitions for on-disk
> encryption.
> diff --git a/package/cryptsetup/cryptsetup.mk b/package/cryptsetup/cryptsetup.mk
> index 5b0310f..33869c7 100644
> --- a/package/cryptsetup/cryptsetup.mk
> +++ b/package/cryptsetup/cryptsetup.mk
> @@ -6,7 +6,6 @@ CRYPTSETUP_SOURCE = cryptsetup-$(CRYPTSETUP_VERSION).tar.bz2
> CRYPTSETUP_SITE = http://cryptsetup.googlecode.com/files
> CRYPTSETUP_INSTALL_STAGING = NO
> CRYPTSETUP_INSTALL_TARGET = YES
> -#CRYPTSETUP_CONF_OPT = --BLAH
> CRYPTSETUP_DEPENDENCIES = lvm2 libgcrypt popt e2fsprogs
>
> $(eval $(call AUTOTARGETS,package,cryptsetup))
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [Buildroot] [PATCH] Add package bonnie++
From: Thomas Petazzoni @ 2011-02-01 21:02 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1296580740-4790-1-git-send-email-mort@bork.org>
Hello,
On Tue, 1 Feb 2011 12:19:00 -0500
Martin Hicks <mort@bork.org> wrote:
> A good filesystem performance benchmark program
>
> Signed-off-by: Martin Hicks <mort@bork.org>
Thanks for this package. Some comments below.
> +config BR2_PACKAGE_BONNIE
> + bool "bonnie++"
> + help
> + Filesystem tester
Here the indent should be one tab + two spaces.
> +BONNIE_VERSION = 1.03e
> +BONNIE_SOURCE = bonnie++-$(BONNIE_VERSION).tgz
> +BONNIE_SITE = http://www.coker.com.au/bonnie++/
> +BONNIE_INSTALL_TARGET_OPT = INSTALL="install -m 0755" install-bin
This is not needed if you override the installation as done below by
BONNE_INSTALL_TARGET_CMDS.
> +define BONNIE_INSTALL_TARGET_CMDS
> + install -D -m 755 $(@D)/bonnie++ $(TARGET_DIR)/usr/sbin
should be
install -D -m 755 $(@D)/bonnie++ $(TARGET_DIR)/usr/sbin/bonnie++
> + install -D -m 755 $(@D)/zcav $(TARGET_DIR)/usr/sbin
should be
install -D -m 755 $(@D)/zcav $(TARGET_DIR)/usr/sbin/zcav
Regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: Kernel 2.6.32-5-amd64 fails to boot.
From: Rudy Zijlstra @ 2011-02-01 21:02 UTC (permalink / raw)
To: lrhorer; +Cc: 'Linux RAID'
In-Reply-To: <1D.26.13137.882784D4@cdptpa-omtalb.mail.rr.com>
On 02/01/2011 09:52 PM, Leslie Rhorer wrote:
>> On 02/01/2011 09:23 PM, Leslie Rhorer wrote:
>>
>>
>>> doesn't boot, either. It gives a bit more detail in the output, but
>>>
>> nothing
>>
>>> illuminating. The old kernel (2.6.32-3-amd64) boots just fine.
>>>
>>>
>> Can you enable serial console and catch the console output that way?
>>
> Well, not easily. I don't have a serial terminal. I suppose I
> could set something up. You're suggesting I poke around to see what md is
> reporting? Also, I'm not sure why - if the keyboard console is failing -
> the serial console would work better.
>
>
>
Serial console can be captured to a file and then the output analysed.
So you can read afterwards the messages that are flying past.
What i do in such case, is that i take serial connector from a laptop,
and run a terminal emulater like minicom. And capture it to a file so i
can analyse what has been happening.
^ permalink raw reply
* Re: User space RAID-6 access
From: Piergiorgio Sartor @ 2011-02-01 21:00 UTC (permalink / raw)
To: NeilBrown; +Cc: Piergiorgio Sartor, linux-raid
In-Reply-To: <20110202071850.3b671c1e@notabene.brown>
> I didn't realise that you wanted to look at the members of the array while
> the array was active!! That is a bit harder. But not impossible.
Well, let's say that would be optimal, but even
off-line could be OK.
BTW, what does it mean "off-line"?
Does it mean that /dev/mdX exists, but it is not
used (un-mounted), or it is just read-only, or
it should *not* exists and only the componing
HDDs are available?
> If you write a couple of numbers to 'suspend_lo' and 'suspend_hi' in sysfs,
> then writes to blocks between those two array addresses will be blocked.
> So you could suspend a region, look at the blocks, then un-suspend.
Oh, thanks, I will consider the option.
bye,
--
piergiorgio
^ permalink raw reply
* [Buildroot] [PATCH] Makefile.package.in: fix upper case $(PKG)_SITE_METHOD
From: Thomas Petazzoni @ 2011-02-01 21:00 UTC (permalink / raw)
To: buildroot
In-Reply-To: <AANLkTikUX0mZAwBhX=xVYYtmHR8gp1K3cBde=w7wpwhH@mail.gmail.com>
On Tue, 1 Feb 2011 21:51:38 +0100
Daniel Nystr?m <daniel.nystrom@timeterminal.se> wrote:
> Maybe, after all, this is a special case where both upper and lower
> case should work?
Hum, why would it be necessary to accept upper case spelling ?
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* test message (add List-ID: header)
From: Benjamin LaHaise @ 2011-02-01 21:00 UTC (permalink / raw)
To: linux-mm
This is a test. Nothing to see. Please ignore the man behind the curtain.
-owner-linux-mm
--
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/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [refpolicy] [PATCH/RFC 2/19]: patch set to update the git reference policy
From: Guido Trentalancia @ 2011-02-01 20:59 UTC (permalink / raw)
To: refpolicy
In-Reply-To: <4D48649C.70000@tresys.com>
Hello Christopher !
On Tue, 01/02/2011 at 14.53 -0500, Christopher J. PeBenito wrote:
> On 02/01/11 15:03, Guido Trentalancia wrote:
> > Hello Christopher !
> >
> > On Tue, 01/02/2011 at 09.05 -0500, Christopher J. PeBenito wrote:
> >> On 01/31/11 18:15, Guido Trentalancia wrote:
> >>> Hello again Christopher !
> >>>
> >>> On Mon, 31/01/2011 at 13.52 -0500, Christopher J. PeBenito wrote:
> >>>> On 1/24/2011 9:24 AM, Dominick Grift wrote:
> >>>>> On 01/24/2011 01:43 AM, Guido Trentalancia wrote:
> >>>>
> >>>> Please include descriptions on each of your patches. The subject is
> >>>> definitely insufficient. I guess this is all the dbus changes you
> >>>> suggest? More
> >>>
> >>> The DBus send_msg issue is the probably the main change introduced by
> >>> the set of patches that I am proposing.
> >>>
> >>> The issue is very wide and needs careful approval. It's not limited to
> >>> this [2/19] patch/thread at all. It is mainly a style issue, but it's an
> >>> important one.
> >>>
> >>> In my reply to [0/19] I have pointed out a few threads where such issue
> >>> has been discussed more extensively between me and Dominick, because we
> >>> kept having different point of views and none of us managed to
> >>> definitely persuade the other !
> >>>
> >>> In any case, [2/19] and [8/19] are perhaps the most relevant places
> >>> where you can provide a definite direction on this (in short, can we
> >>> really talk about an hypothetical DBus "chat" throughout all refpolicy
> >>> and model interfaces accordingly to such assumption when on the other
> >>> hand the elementary data-flow in DBus is constituted by a
> >>> uni-directional message called "signal" ?).
> >>
> >> There already is an established verb for unidirectional dbus messaging:
> >> send. See unconfined_dbus_send() for an example. If there is
> >> unidirectional messaging, the policy should reflect that.
> >
> > Yes, unconfined_dbus_send() can be used in the context of the unconfined
> > domain.
> >
> > But then there are many other circumstances where DBus messaging needs
> > to take place. My original dbus-messaging patch ([2/19]) contains
> > several examples of where this appears to be needed.
> >
> > I prefer to grant two distinct and separate uni-directional send_msg
> > permissions in the two relevant modules anyway (even in the case of
> > bi-directional messaging).
>
> I'm not sure if I understand. Are you saying that you want to break
> apart the chat interfaces into individual send interfaces?
>
> eg:
>
> networkmanager_dbus_chat(hald_t)
>
> turns into
>
> networkmanager_dbus_send(hald_t)
> hald_dbus_send(networkmanager_t)
>
> (of course these would be in the proper modules)
>
> > Therefore, I have always created new *_dbus_send() interfaces even where
> > *_dbus_chat() interfaces were present (and could in theory be used).
>
> I don't have a problem with this.
Yes, I was referring exactly to that. Excellent.
Thanks a lot for your advice.
Best regards,
Guido
^ permalink raw reply
* Re: [PATCH] perf: Cure task_oncpu_function_call() races
From: Peter Zijlstra @ 2011-02-01 21:00 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Frederic Weisbecker, Ingo Molnar, Alan Stern,
Arnaldo Carvalho de Melo, Paul Mackerras, Prasad, Roland McGrath,
linux-kernel
In-Reply-To: <1296583698.26581.279.camel@laptop>
On Tue, 2011-02-01 at 19:08 +0100, Peter Zijlstra wrote:
> perf_install_in_context() works on a ctx obtained by find_get_context(),
> that context is either new (uncloned) or existing in which case it
> called unclone_ctx(). So I was thinking there was no race with the ctx
> flipping in perf_event_context_sched_out(), _however_ since it only
> acquires ctx->mutex after calling unclone_ctx() there is a race window
> with perf_event_init_task().
>
> This race we should fix with perf_pin_task_context()
I came up with the below.. I'll give it some runtime tomorrow, my brain
just gave up for today..
---
Index: linux-2.6/kernel/perf_event.c
===================================================================
--- linux-2.6.orig/kernel/perf_event.c
+++ linux-2.6/kernel/perf_event.c
@@ -327,7 +327,6 @@ static void perf_unpin_context(struct pe
raw_spin_lock_irqsave(&ctx->lock, flags);
--ctx->pin_count;
raw_spin_unlock_irqrestore(&ctx->lock, flags);
- put_ctx(ctx);
}
/*
@@ -741,10 +740,10 @@ static void perf_remove_from_context(str
raw_spin_lock_irq(&ctx->lock);
/*
- * If we failed to find a running task, but find it running now that
- * we've acquired the ctx->lock, retry.
+ * If we failed to find a running task, but find the context active now
+ * that we've acquired the ctx->lock, retry.
*/
- if (task_curr(task)) {
+ if (ctx->is_active) {
raw_spin_unlock_irq(&ctx->lock);
goto retry;
}
@@ -1104,10 +1103,10 @@ perf_install_in_context(struct perf_even
raw_spin_lock_irq(&ctx->lock);
/*
- * If we failed to find a running task, but find it running now that
- * we've acquired the ctx->lock, retry.
+ * If we failed to find a running task, but find the context active now
+ * that we've acquired the ctx->lock, retry.
*/
- if (task_curr(task)) {
+ if (ctx->is_active) {
raw_spin_unlock_irq(&ctx->lock);
goto retry;
}
@@ -2278,6 +2277,9 @@ find_lively_task_by_vpid(pid_t vpid)
}
+/*
+ * Returns a matching context with refcount and pincount.
+ */
static struct perf_event_context *
find_get_context(struct pmu *pmu, struct task_struct *task, int cpu)
{
@@ -2302,6 +2304,7 @@ find_get_context(struct pmu *pmu, struct
cpuctx = per_cpu_ptr(pmu->pmu_cpu_context, cpu);
ctx = &cpuctx->ctx;
get_ctx(ctx);
+ ++ctx->pin_count;
return ctx;
}
@@ -2315,6 +2318,7 @@ find_get_context(struct pmu *pmu, struct
ctx = perf_lock_task_context(task, ctxn, &flags);
if (ctx) {
unclone_ctx(ctx);
+ ++ctx->pin_count;
raw_spin_unlock_irqrestore(&ctx->lock, flags);
}
@@ -6041,6 +6045,7 @@ SYSCALL_DEFINE5(perf_event_open,
perf_install_in_context(ctx, event, cpu);
++ctx->generation;
+ perf_unpin_context(ctx);
mutex_unlock(&ctx->mutex);
event->owner = current;
@@ -6066,6 +6071,7 @@ SYSCALL_DEFINE5(perf_event_open,
return event_fd;
err_context:
+ perf_unpin_context(ctx);
put_ctx(ctx);
err_alloc:
free_event(event);
@@ -6116,6 +6122,7 @@ perf_event_create_kernel_counter(struct
mutex_lock(&ctx->mutex);
perf_install_in_context(ctx, event, cpu);
++ctx->generation;
+ perf_unpin_context(ctx);
mutex_unlock(&ctx->mutex);
return event;
@@ -6591,6 +6598,7 @@ int perf_event_init_context(struct task_
mutex_unlock(&parent_ctx->mutex);
perf_unpin_context(parent_ctx);
+ put_ctx(parent_ctx);
return ret;
}
^ permalink raw reply
* Re: Locking in the clk API, part 2: clk_prepare/clk_unprepare
From: Stephen Boyd @ 2011-02-01 20:59 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Uwe Kleine-König, Nicolas Pitre, Lorenzo Pieralisi,
Saravana Kannan, linux-sh, Ben Herrenschmidt, Sascha Hauer,
Paul Mundt, linux-kernel, Dima Zavin, Ben Dooks, Vincent Guittot,
Jeremy Kerr, linux-arm-kernel
In-Reply-To: <20110201152458.GP31216@n2100.arm.linux.org.uk>
On 02/01/2011 07:24 AM, Russell King - ARM Linux wrote:
>
> I'd also be tempted at this stage to build-in a no-op dummy clock,
> that being the NULL clk:
>
> int clk_prepare(struct clk *clk)
> {
> int ret = 0;
>
> if (clk) {
> mutex_lock(&clk->mutex);
> if (clk->prepared == 0)
> ret = clk->ops->prepare(clk);
> if (ret == 0)
> clk->prepared++;
> mutex_unlock(&clk->mutex);
> }
>
> return ret;
> }
I'm afraid this will hide enable/disable imbalances on some targets and
then expose them on others. Maybe its not a big problem though since
this also elegantly handles the root(s) of the tree.
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Locking in the clk API, part 2: clk_prepare/clk_unprepare
From: Stephen Boyd @ 2011-02-01 20:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110201152458.GP31216@n2100.arm.linux.org.uk>
On 02/01/2011 07:24 AM, Russell King - ARM Linux wrote:
>
> I'd also be tempted at this stage to build-in a no-op dummy clock,
> that being the NULL clk:
>
> int clk_prepare(struct clk *clk)
> {
> int ret = 0;
>
> if (clk) {
> mutex_lock(&clk->mutex);
> if (clk->prepared == 0)
> ret = clk->ops->prepare(clk);
> if (ret == 0)
> clk->prepared++;
> mutex_unlock(&clk->mutex);
> }
>
> return ret;
> }
I'm afraid this will hide enable/disable imbalances on some targets and
then expose them on others. Maybe its not a big problem though since
this also elegantly handles the root(s) of the tree.
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: Locking in the clk API, part 2: clk_prepare/clk_unprepare
From: Stephen Boyd @ 2011-02-01 20:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110201152458.GP31216@n2100.arm.linux.org.uk>
On 02/01/2011 07:24 AM, Russell King - ARM Linux wrote:
>
> I'd also be tempted at this stage to build-in a no-op dummy clock,
> that being the NULL clk:
>
> int clk_prepare(struct clk *clk)
> {
> int ret = 0;
>
> if (clk) {
> mutex_lock(&clk->mutex);
> if (clk->prepared = 0)
> ret = clk->ops->prepare(clk);
> if (ret = 0)
> clk->prepared++;
> mutex_unlock(&clk->mutex);
> }
>
> return ret;
> }
I'm afraid this will hide enable/disable imbalances on some targets and
then expose them on others. Maybe its not a big problem though since
this also elegantly handles the root(s) of the tree.
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: [PATCH] usb:smsc: preserve MAC address when resetting device
From: Sergiy Kibrik @ 2011-02-01 20:58 UTC (permalink / raw)
To: David Lamparter; +Cc: Steve Glendinning, netdev, linux-usb
In-Reply-To: <20110201112425.GA3407894@jupiter.n2.diac24.net>
[-- Attachment #1: Type: Text/Plain, Size: 448 bytes --]
On Tuesday 01 February 2011 13:24:25 David Lamparter wrote:
> You cannot do that. Imagine if I plug in two devices. Only the first one
> will get a MAC properly. Or imagine if i plug a device, unplug it and
> plug it back. It will have an uninitialized mac address.
>
> You need to move the init_mac_address call to happen on device plug-in.
>
>
> -David
Sorry, didn't take into account such case. Will resubmit
-regards,
Sergey
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 316 bytes --]
^ permalink raw reply
* Re: What's the typical RAID10 setup?
From: Roberto Spadim @ 2011-02-01 20:58 UTC (permalink / raw)
To: Keld Jørn Simonsen; +Cc: David Brown, linux-raid
In-Reply-To: <20110201203210.GB26468@www2.open-std.org>
> For sequential reading, this is not true. For random reading and
> writing I agree with you in theory, but benchmarks show that it is not
> so, at least for Linux RAID, viz the above URL.
i agree with you, since linux algorith for raid1 is closest head, not
round robin or time based
there´s some patch on internet (google it: round robin raid1 linux)
for roundrobin, but none for time based =(
it´s a point of optimization of today raid1 algorithm
round robin (may be at this mail list)
http://www.spinics.net/lists/raid/msg30003.html
2011/2/1 Keld Jørn Simonsen <keld@keldix.com>:
> On Tue, Feb 01, 2011 at 05:02:46PM +0100, Keld Jørn Simonsen wrote:
>> On Tue, Feb 01, 2011 at 11:01:33AM +0100, David Brown wrote:
>> > On 31/01/2011 23:52, Keld Jørn Simonsen wrote:
>> > >raid1+0 and Linux MD raid10 are similar, but significantly different
>> > >in a number of ways. Linux MD raid10 can run on only 2 drives.
>> > >Linux raid10,f2 has almost RAID0 striping performance in sequential read.
>> > >You can have an odd number of drives in raid10.
>> > >And you can have as many copies as you like in raid10,
>> > >
>> >
>> > You can make raid10,f2 functionality from raid1+0 by using partitions.
>> > For example, to get a raid10,f2 equivalent on two drives, partition them
>> > into equal halves. Then make md0 a raid1 mirror of sda1 and sdb2, and
>> > md1 a raid1 mirror of sdb1 and sda2. Finally, make md2 a raid0 stripe
>> > set of md0 and md1.
>>
>> I don't think you get the striping performance of raid10,f2 with this
>> layout. And that is one of the main advantages of raid10,f2 layout.
>> Have you tried it out?
>>
>> As far as I can see the layout of blocks are not alternating between the
>> disks. You have one raid1 of sda1 and sdb2, there a file is allocated on
>> blocks sequentially on sda1 and then mirrored on sdb2, where it is also
>> sequentially allocated. That gives no striping.
>
> Well, maybe the RAID0 layer provides the adequate striping.
> I am noy sure, but it looks like it could hold in theory.
> One could try it out.
>
> One advantage of this scheme could be improved probability
> When 2 drives fail, eg. in the case of a 4 drive array.
> The probability of survival of a running system could then
> be enhaced form 33 % to 66 %.
>
> One problem could be the choice of always the lowest block number, which
> is secured in raid10,f2, but not in a raid0 over raid1 (or raid10,n2) scenario.
>
> best regards
> keld
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Roberto Spadim
Spadim Technology / SPAEmpresarial
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 01/18] wl1251: fix queue stopping/waking for TX path
From: Kalle Valo @ 2011-02-01 20:58 UTC (permalink / raw)
To: David Gnedt
Cc: John W. Linville, linux-wireless, Grazvydas Ignotas,
Denis 'GNUtoo' Carikli
In-Reply-To: <4D45B7B6.4090102@davizone.at>
David Gnedt <david.gnedt@davizone.at> writes:
> The queue stopping/waking functionality was broken in a way that could
> cause the TX to stall if the right circumstances are met.
>
> The problem was caused by tx_work, which is scheduled on each TX operation.
> If the firmware buffer is full, tx_work does nothing. In combinition with
> stopped queues or non-continues transfers, tx_work is never scheduled again.
> Moreover the low watermark introduced by
> 9df86e2e702c6d5547aced7f241addd2d698bb11 never takes effect because of some
> old code.
>
> Solve this by scheduling tx_work every time tx_queue is non-empty and
> firmware buffer is freed on tx_complete.
>
> This also solves a possible but unlikely case: If less frames than the high
> watermark are queued, but more than firmware buffer can hold. This results
> in queues staying awake but the only scheduled tx_work doesn't transfer all
> frames, so the remaining frames are stuck in the queue until more frames
> get queued and tx_work is scheduled again.
This looks good. Unfortunately I wasn't able to test it yet, but if it
solves your issue I think it's best to get it in now.
Thanks for fixing this.
> Signed-off-by: David Gnedt <david.gnedt@davizone.at>
Acked-by: Kalle Valo <kvalo@adurom.com>
--
Kalle Valo
^ 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.