* Re: [RFC PATCH] mm: handle simple case in free_pcppages_bulk()
From: Mel Gorman @ 2011-02-10 14:05 UTC (permalink / raw)
To: Minchan Kim; +Cc: Namhyung Kim, Andrew Morton, linux-mm, linux-kernel
In-Reply-To: <AANLkTimcLgsdEm6XKESc34Z=nsJkZqz8H1jR-ARZo_Gq@mail.gmail.com>
On Thu, Feb 10, 2011 at 10:38:59PM +0900, Minchan Kim wrote:
> On Thu, Feb 10, 2011 at 10:18 PM, Namhyung Kim <namhyung@gmail.com> wrote:
> > 2011-02-10 (???), 22:10 +0900, Minchan Kim:
> >> Hello Namhyung,
> >>
> >
> > Hi Minchan,
> >
> >
> >> On Thu, Feb 10, 2011 at 8:46 PM, Namhyung Kim <namhyung@gmail.com> wrote:
> >> > Now I'm seeing that there are some cases to free all pages in a
> >> > pcp lists. In that case, just frees all pages in the lists instead
> >> > of being bothered with round-robin lists traversal.
> >>
> >> I though about that but I didn't send the patch.
> >> That's because many cases which calls free_pcppages_bulk(,
> >> pcp->count,..) are slow path so it adds comparison overhead on fast
> >> path while it loses the effectiveness in slow path.
> >>
> >
> > Hmm.. How about adding unlikely() then? Doesn't it help much here?
>
> Yes. It would help but I am not sure how much it is.
> AFAIR, when Mel submit the patch, he tried to prove the effectiveness
> with some experiment and profiler.
Yep. Principally I *think* used netperf running UDP_STREAM for different
buffer sizes and compared oprofile output but I also ran a battery of
benchmarks to check for any other unexpected regression without profiling.
--
Mel Gorman
SUSE Labs
^ permalink raw reply
* Re: [RFC PATCH] mm: handle simple case in free_pcppages_bulk()
From: Mel Gorman @ 2011-02-10 14:05 UTC (permalink / raw)
To: Minchan Kim; +Cc: Namhyung Kim, Andrew Morton, linux-mm, linux-kernel
In-Reply-To: <AANLkTimcLgsdEm6XKESc34Z=nsJkZqz8H1jR-ARZo_Gq@mail.gmail.com>
On Thu, Feb 10, 2011 at 10:38:59PM +0900, Minchan Kim wrote:
> On Thu, Feb 10, 2011 at 10:18 PM, Namhyung Kim <namhyung@gmail.com> wrote:
> > 2011-02-10 (???), 22:10 +0900, Minchan Kim:
> >> Hello Namhyung,
> >>
> >
> > Hi Minchan,
> >
> >
> >> On Thu, Feb 10, 2011 at 8:46 PM, Namhyung Kim <namhyung@gmail.com> wrote:
> >> > Now I'm seeing that there are some cases to free all pages in a
> >> > pcp lists. In that case, just frees all pages in the lists instead
> >> > of being bothered with round-robin lists traversal.
> >>
> >> I though about that but I didn't send the patch.
> >> That's because many cases which calls free_pcppages_bulk(,
> >> pcp->count,..) are slow path so it adds comparison overhead on fast
> >> path while it loses the effectiveness in slow path.
> >>
> >
> > Hmm.. How about adding unlikely() then? Doesn't it help much here?
>
> Yes. It would help but I am not sure how much it is.
> AFAIR, when Mel submit the patch, he tried to prove the effectiveness
> with some experiment and profiler.
Yep. Principally I *think* used netperf running UDP_STREAM for different
buffer sizes and compared oprofile output but I also ran a battery of
benchmarks to check for any other unexpected regression without profiling.
--
Mel Gorman
SUSE Labs
--
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 internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PULL] Consolidated Pull Request
From: Richard Purdie @ 2011-02-10 14:05 UTC (permalink / raw)
To: Saul Wold; +Cc: poky@yoctoproject.org
In-Reply-To: <4D52C5D2.4070006@linux.intel.com>
On Wed, 2011-02-09 at 08:50 -0800, Saul Wold wrote:
> Richard,
>
> Here are some a set of batched changes for docs, image-mklibs.bbclass
> (to enable using mklibs) and the mesa update for removing the Talloc
> dependency.
>
> Please review and pull.
>
> Pull URL: git://git.pokylinux.org/poky-contrib.git
> Branch: distro/master
> Browse:
> http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=distro/master
>
> Thanks,
> Saul Wold <sgw@linux.intel.com>
These were merged into master, thanks.
Richard
^ permalink raw reply
* Re: [PATCH] Btrfs-progs use safe string manipulation functions
From: Olaf van der Spek @ 2011-02-10 14:05 UTC (permalink / raw)
To: Eduardo Silva; +Cc: Jeremy Sanders, linux-btrfs
In-Reply-To: <1297346453.28159.17.camel@monotop>
On Thu, Feb 10, 2011 at 3:00 PM, Eduardo Silva <eduardo.silva@oracle.co=
m> wrote:
> On Thu, 2011-02-10 at 14:52 +0100, Olaf van der Spek wrote:
>> On Thu, Feb 10, 2011 at 2:37 PM, Eduardo Silva <eduardo.silva@oracle=
=2Ecom> wrote:
>> > string_copy seems pointless, it's kinda equivalent to strcpy.
>> >
>> > Yeah, but if we are thinking into write some wrappers let's create=
a couple
>> > for the major string manipulation used...
>>
>> A wrapper should have a benefit, your string_copy doesn't have any.
>
> It have it, take this example:
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0char *a;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0a =3D malloc(1024);
> =C2=A0 =C2=A0 =C2=A0 =C2=A0strcpy(a, NULL);
>
> at least with the wrapper you will get a notice about what's going
> on...
The debugger shows you what's going on without wrapper.
--=20
Olaf
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
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] ix86: re-do permanent disabling of x2apic
From: Christoph Egger @ 2011-02-10 14:05 UTC (permalink / raw)
To: xen-devel; +Cc: Gang Wei, Jan Beulich
In-Reply-To: <4D53FB2702000078000313E3@vpn.id2.novell.com>
Wouldn't it be better to factor out 32bit and 64bit functions into new files
in the x86_32 and x86_64 subdirectories and just call them from here?
On Thursday 10 February 2011 14:50:15 Jan Beulich wrote:
> Move logic into check_x2apic_preenabled() (to make sure
> generic_apic_probe() doesn't see genapic already set) and disable dead
> code on ix86.
>
> Signed-off-by: Jan Beulich <jbeulich@novell.com>
>
> --- a/xen/arch/x86/apic.c
> +++ b/xen/arch/x86/apic.c
> @@ -71,10 +71,12 @@ static int enable_local_apic __initdata
> */
> int apic_verbosity;
>
> +#ifndef __i386__
> static bool_t __initdata opt_x2apic = 1;
> boolean_param("x2apic", opt_x2apic);
>
> bool_t __read_mostly x2apic_enabled = 0;
> +#endif
> bool_t __read_mostly directed_eoi_enabled = 0;
>
> /*
> @@ -962,20 +964,8 @@ void __init x2apic_bsp_setup(void)
> return;
>
> #ifdef __i386__
> - clear_bit(X86_FEATURE_X2APIC, boot_cpu_data.x86_capability);
> - if ( x2apic_enabled )
> - {
> - uint64_t msr_content;
> - rdmsrl(MSR_IA32_APICBASE, msr_content);
> - msr_content &= ~(MSR_IA32_APICBASE_ENABLE |
> MSR_IA32_APICBASE_EXTD); - wrmsrl(MSR_IA32_APICBASE, msr_content);
> - msr_content |= MSR_IA32_APICBASE_ENABLE;
> - wrmsrl(MSR_IA32_APICBASE, msr_content);
> - x2apic_enabled = 0;
> - }
> - printk("x2APIC disabled permanently on x86_32.\n");
> - return;
> -#endif
> + BUG();
> +#else
>
> if ( !opt_x2apic )
> {
> @@ -1038,6 +1028,7 @@ restore_out:
> unmask_8259A();
>
> out:
> +#endif /* !__i386__ */
> if ( ioapic_entries )
> free_ioapic_entries(ioapic_entries);
> }
> --- a/xen/arch/x86/genapic/x2apic.c
> +++ b/xen/arch/x86/genapic/x2apic.c
> @@ -29,6 +29,8 @@
> #include <xen/smp.h>
> #include <asm/mach-default/mach_mpparse.h>
>
> +#ifndef __i386__
> +
> static bool_t __initdata x2apic_phys; /* By default we use logical cluster
> mode. */ boolean_param("x2apic_phys", x2apic_phys);
>
> @@ -126,6 +128,8 @@ const struct genapic *__init apic_x2apic
> return x2apic_phys ? &apic_x2apic_phys : &apic_x2apic_cluster;
> }
>
> +#endif /* !__i386__ */
> +
> void __init check_x2apic_preenabled(void)
> {
> u32 lo, hi;
> @@ -138,7 +142,19 @@ void __init check_x2apic_preenabled(void
> if ( lo & MSR_IA32_APICBASE_EXTD )
> {
> printk("x2APIC mode is already enabled by BIOS.\n");
> +#ifndef __i386__
> x2apic_enabled = 1;
> genapic = apic_x2apic_probe();
> +#else
> + lo &= ~(MSR_IA32_APICBASE_ENABLE | MSR_IA32_APICBASE_EXTD);
> + wrmsr(MSR_IA32_APICBASE, lo, hi);
> + lo |= MSR_IA32_APICBASE_ENABLE;
> + wrmsr(MSR_IA32_APICBASE, lo, hi);
> + printk("x2APIC disabled permanently on x86_32.\n");
> +#endif
> }
> +
> +#ifdef __i386__
> + clear_bit(X86_FEATURE_X2APIC, boot_cpu_data.x86_capability);
> +#endif
> }
> --- a/xen/include/asm-x86/apic.h
> +++ b/xen/include/asm-x86/apic.h
> @@ -22,7 +22,11 @@
> #define IO_APIC_REDIR_DEST_PHYSICAL 0x00000
>
> extern int apic_verbosity;
> +#ifdef __i386__
> +#define x2apic_enabled 0
> +#else
> extern bool_t x2apic_enabled;
> +#endif
> extern bool_t directed_eoi_enabled;
>
> void check_x2apic_preenabled(void);
--
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632
^ permalink raw reply
* Re: [Qemu-devel] KVM call minutes for Feb 8
From: Anthony Liguori @ 2011-02-10 14:04 UTC (permalink / raw)
To: Gleb Natapov
Cc: Chris Wright, kvm, Markus Armbruster, qemu-devel, Blue Swirl,
Avi Kivity
In-Reply-To: <20110210132730.GB24525@redhat.com>
On 02/10/2011 02:27 PM, Gleb Natapov wrote:
> I don't care how command line will look like, but I do not see how you
> will support ide=off without device composition unless you put ad-hoc
> ifs all over your i440fx device code.
>
Yes, in the piix3 device code, the ide property would trigger an if().
BTW, I'm extremely sceptical that you really do have machines w/o IDE at
all. Even the servers we ship with only SAS or SCSI support still have
an integrated IDE controller.
Since most servers are built from the same chipset design that has IDE,
I don't really see how you could build a modern system without IDE.
>> And that's okay, but the base modelling ought to follow rea
>> hardware closely with deviations being the exception.
>>
>>
> You keep saying this without explaining why. But with device composition
> you will have exactly that, you will compose real chipsets using config
> files, not code.
>
Yeah, that's been the direction we've been going in since qdev was
introduced. I'm now convinced that this is overly ambitious. By simply
reducing the scope of conversion, we get 99% of the benefit with 10% of
the effort. Seems like a no brainer to me.
Regards,
Anthony Liguori
> --
> Gleb.
>
>
^ permalink raw reply
* Re: Numonyx NOR and chip->mutex bug?
From: Joakim Tjernlund @ 2011-02-10 14:04 UTC (permalink / raw)
To: Anders Grafström
Cc: linux-mtd, Holger brunck, stefan.bigler, Michael Cashwell
In-Reply-To: <4D53E660.4020305@users.sourceforge.net>
Anders Grafström <grfstrm@users.sourceforge.net> wrote on 2011/02/10 14:21:36:
>
> On 2011-02-09 22:59, Michael Cashwell wrote:
> > On Feb 9, 2011, at 3:13 PM, Joakim Tjernlund wrote:
> >
> >> hmm, this sounds similar(from http://www.numonyx.com/Documents/Specification%20Updates/SU-309045_P30.pdf)
> >>
> >> 5. W602: erase suspend resume operation
> >> Problem: P30 product may fail to erase in intensive erase/suspend/resume environments. This is
> >> due to an internal firmware issue that is exhibited in certain applications that require at
> >> least 3000 to 4000 erase/suspend/resume cycles during the erase of a single block.
> >> Implication: Customer may see erase failure (SR reports “A0”) during a background erase. This
> >> does not damage the device in any way, but data in the block may be disturbed from its
> >> original state.
>
> I've seen this issue with Intel 28F640J5 chips as well.
>
> There's an old thread on it.
> http://lists.infradead.org/pipermail/linux-mtd/2008-April/021266.html
>
> A delay was suggested similar to the one you're experimenting with I think.
> http://lists.infradead.org/pipermail/linux-mtd/2008-April/021436.html
Oh, I had forgotten about this thread :)
I agree with the latency theory, for Numonyx there is this:
W602 is the typical time between an initial block erase or erase resume command and the a subsequent erase suspend
command. Violating the specification repeatedly during any particular block erase may cause erase failures.
W602 is defined to 500us
Adding a delay after resume will do it but is a bit crude. Possibly one
could add a timestamp at resume/initial erase and a check in suspend that enough time has passed
before suspending again.
How does that sound?
Jocke
^ permalink raw reply
* Re: Fetch problems with PREMIRRORS
From: Richard Purdie @ 2011-02-10 14:03 UTC (permalink / raw)
To: Gary Thomas; +Cc: Poky
In-Reply-To: <4D529954.4000505@mlbassoc.com>
On Wed, 2011-02-09 at 06:40 -0700, Gary Thomas wrote:
> Per Richard's suggestion, I have added this to my DISTRO.conf:
>
> # Provide pre-staged sources
> PREMIRRORS = "\
> http://.*/.* file:///work/misc/Poky/sources/ \n \
> https://.*/.* file:///work/misc/Poky/sources/ \n \
> ftp://.*/.* file:///work/misc/Poky/sources/ \n \
> bzr://.*/.* file:///work/misc/Poky/sources/ \n \
> cvs://.*/.* file:///work/misc/Poky/sources/ \n \
> git://.*/.* file:///work/misc/Poky/sources/ \n \
> hg://.*/.* file:///work/misc/Poky/sources/ \n \
> osc://.*/.* file:///work/misc/Poky/sources/ \n \
> p4://.*/.* file:///work/misc/Poky/sources/ \n \
> svk://.*/.* file:///work/misc/Poky/sources/ \n \
> svn://.*/.* file:///work/misc/Poky/sources/ \n"
>
> The tree '/work/misc/Poky/sources' is a fully populated source
> cache.
>
> This all works great as long as the needed sources are in
> the cache. However, there seems to be no fallback if they
> are not present. I get errors like this:
> | NOTE: fetch http://pokylinux.org/sources/git2_github.com.wrpseudo.pseudo.git.tar.gz
> | NOTE: fetch http://autobuilder.pokylinux.org/sources/git2_github.com.wrpseudo.pseudo.git.tar.gz
> | ERROR: Function 'Fetcher failure for URL: 'git://github.com/wrpseudo/pseudo.git;protocol=git'. Unable to fetch URL git://github.com/wrpseudo/pseudo.git;protocol=git from any
> source.' failed
> NOTE: package pseudo-native-0.0+git1+5434325fc887817ebb2bad36313d8277992cef1d-r18: task Fetcher failure for URL: 'git://github.com/wrpseudo/pseudo.git;protocol=git'. Unable to
> fetch URL git://github.com/wrpseudo/pseudo.git;protocol=git from any source.: Failed
>
> In order to actually fetch, I have to remove the PREMIRRORS
> from my conf.
>
> Is there some way to get it to use the source cache but
> still fetch when needed?
>
> Thanks
>
> Note: I also normally have BB_NO_NETWORK="1", but that is not
> applicable here (no message about it) and setting it false does
> not change the behaviour.
It is applicable.
Try not setting that variable at all, not setting it false. I suspect
there are two issues here:
a) BB_NO_NETWORK is having an effect but the log messages are being
swallowed...
b) "false" handling for the variable might not be working properly so
leave it unset.
We can fix those things but I'd like to confirm these are the problems
first.
Cheers,
Richard
^ permalink raw reply
* Re: [Qemu-devel] KVM call minutes for Feb 8
From: Anthony Liguori @ 2011-02-10 14:00 UTC (permalink / raw)
To: Avi Kivity
Cc: Chris Wright, Gleb Natapov, kvm, qemu-devel, Markus Armbruster,
Blue Swirl
In-Reply-To: <4D53E155.5000807@redhat.com>
On 02/10/2011 02:00 PM, Avi Kivity wrote:
> On 02/10/2011 02:51 PM, Anthony Liguori wrote:
>> On 02/10/2011 12:13 PM, Gleb Natapov wrote:
>>>
>>> Which spec? Even in this discussion we completely mixed different
>>> things. 440FX is not a chipset.
>>
>> Yes, it is. It's a single silicon package with a defined pinout. If
>> you don't believe me, re-read the spec.
>>
>> It's a MCM with the PIIX3 being internally connected. The
>> connection between the i440fx and PIIX3 happens to be PCI but that's
>> not always the case. Sometimes it's a proprietary bus.
>
> Aren't they two distinct chips, together comprising the chip-set?
>
> One (the northbridge) converts the system bus to PCI + some extra
> wires, the other (southbridge) bridges PCI to ISA and contains some
> embedded ISA devices. IIRC there are some wires between them that are
> not PCI.
Yes, you are correct. So I can understand an argument for:
-device i440fx,id=pmc -device piix3,chipset=pmc
Or something like that.
Regards,
Anthony Liguori
^ permalink raw reply
* Re: [Qemu-devel] KVM call minutes for Feb 8
From: Anthony Liguori @ 2011-02-10 14:00 UTC (permalink / raw)
To: Avi Kivity
Cc: Chris Wright, Gleb Natapov, kvm, Markus Armbruster, qemu-devel,
Blue Swirl
In-Reply-To: <4D53E155.5000807@redhat.com>
On 02/10/2011 02:00 PM, Avi Kivity wrote:
> On 02/10/2011 02:51 PM, Anthony Liguori wrote:
>> On 02/10/2011 12:13 PM, Gleb Natapov wrote:
>>>
>>> Which spec? Even in this discussion we completely mixed different
>>> things. 440FX is not a chipset.
>>
>> Yes, it is. It's a single silicon package with a defined pinout. If
>> you don't believe me, re-read the spec.
>>
>> It's a MCM with the PIIX3 being internally connected. The
>> connection between the i440fx and PIIX3 happens to be PCI but that's
>> not always the case. Sometimes it's a proprietary bus.
>
> Aren't they two distinct chips, together comprising the chip-set?
>
> One (the northbridge) converts the system bus to PCI + some extra
> wires, the other (southbridge) bridges PCI to ISA and contains some
> embedded ISA devices. IIRC there are some wires between them that are
> not PCI.
Yes, you are correct. So I can understand an argument for:
-device i440fx,id=pmc -device piix3,chipset=pmc
Or something like that.
Regards,
Anthony Liguori
^ permalink raw reply
* Re: [PATCH] Btrfs-progs use safe string manipulation functions
From: Eduardo Silva @ 2011-02-10 14:00 UTC (permalink / raw)
To: Olaf van der Spek; +Cc: Jeremy Sanders, linux-btrfs
In-Reply-To: <AANLkTi=0wroct+WA7r6931NBhYBtdj7PjheVSFQYp3WE@mail.gmail.com>
On Thu, 2011-02-10 at 14:52 +0100, Olaf van der Spek wrote:
> On Thu, Feb 10, 2011 at 2:37 PM, Eduardo Silva <eduardo.silva@oracle.com> wrote:
> > string_copy seems pointless, it's kinda equivalent to strcpy.
> >
> > Yeah, but if we are thinking into write some wrappers let's create a couple
> > for the major string manipulation used...
>
> A wrapper should have a benefit, your string_copy doesn't have any.
It have it, take this example:
char *a;
a = malloc(1024);
strcpy(a, NULL);
at least with the wrapper you will get a notice about what's going
on...
^ permalink raw reply
* [Qemu-devel] [PATCH 2/2] linux-user/arm: fix compilation failures using softfloat's struct types
From: Peter Maydell @ 2011-02-10 13:59 UTC (permalink / raw)
To: qemu-devel; +Cc: patches
In-Reply-To: <1297346375-11461-1-git-send-email-peter.maydell@linaro.org>
Add uses of the float32/float64 boxing and unboxing macros so that
the ARM linux-user targets will compile with USE_SOFTFLOAT_STRUCT_TYPES
enabled.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
linux-user/arm/nwfpe/fpa11_cpdt.c | 2 +-
linux-user/arm/nwfpe/fpopcode.c | 32 ++++++++++++++++----------------
linux-user/signal.c | 4 ++--
3 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/linux-user/arm/nwfpe/fpa11_cpdt.c b/linux-user/arm/nwfpe/fpa11_cpdt.c
index 1346fd6..b12e27d 100644
--- a/linux-user/arm/nwfpe/fpa11_cpdt.c
+++ b/linux-user/arm/nwfpe/fpa11_cpdt.c
@@ -33,7 +33,7 @@ void loadSingle(const unsigned int Fn, target_ulong addr)
FPA11 *fpa11 = GET_FPA11();
fpa11->fType[Fn] = typeSingle;
/* FIXME - handle failure of get_user() */
- get_user_u32(fpa11->fpreg[Fn].fSingle, addr);
+ get_user_u32(float32_val(fpa11->fpreg[Fn].fSingle), addr);
}
static inline
diff --git a/linux-user/arm/nwfpe/fpopcode.c b/linux-user/arm/nwfpe/fpopcode.c
index 240061d..82ac92f 100644
--- a/linux-user/arm/nwfpe/fpopcode.c
+++ b/linux-user/arm/nwfpe/fpopcode.c
@@ -37,25 +37,25 @@ const floatx80 floatx80Constant[] = {
};
const float64 float64Constant[] = {
- 0x0000000000000000ULL, /* double 0.0 */
- 0x3ff0000000000000ULL, /* double 1.0 */
- 0x4000000000000000ULL, /* double 2.0 */
- 0x4008000000000000ULL, /* double 3.0 */
- 0x4010000000000000ULL, /* double 4.0 */
- 0x4014000000000000ULL, /* double 5.0 */
- 0x3fe0000000000000ULL, /* double 0.5 */
- 0x4024000000000000ULL /* double 10.0 */
+ const_float64(0x0000000000000000ULL), /* double 0.0 */
+ const_float64(0x3ff0000000000000ULL), /* double 1.0 */
+ const_float64(0x4000000000000000ULL), /* double 2.0 */
+ const_float64(0x4008000000000000ULL), /* double 3.0 */
+ const_float64(0x4010000000000000ULL), /* double 4.0 */
+ const_float64(0x4014000000000000ULL), /* double 5.0 */
+ const_float64(0x3fe0000000000000ULL), /* double 0.5 */
+ const_float64(0x4024000000000000ULL) /* double 10.0 */
};
const float32 float32Constant[] = {
- 0x00000000, /* single 0.0 */
- 0x3f800000, /* single 1.0 */
- 0x40000000, /* single 2.0 */
- 0x40400000, /* single 3.0 */
- 0x40800000, /* single 4.0 */
- 0x40a00000, /* single 5.0 */
- 0x3f000000, /* single 0.5 */
- 0x41200000 /* single 10.0 */
+ const_float32(0x00000000), /* single 0.0 */
+ const_float32(0x3f800000), /* single 1.0 */
+ const_float32(0x40000000), /* single 2.0 */
+ const_float32(0x40400000), /* single 3.0 */
+ const_float32(0x40800000), /* single 4.0 */
+ const_float32(0x40a00000), /* single 5.0 */
+ const_float32(0x3f000000), /* single 0.5 */
+ const_float32(0x41200000) /* single 10.0 */
};
unsigned int getRegisterCount(const unsigned int opcode)
diff --git a/linux-user/signal.c b/linux-user/signal.c
index b01bd64..ce033e9 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -1299,7 +1299,7 @@ static abi_ulong *setup_sigframe_v2_vfp(abi_ulong *regspace, CPUState *env)
__put_user(TARGET_VFP_MAGIC, &vfpframe->magic);
__put_user(sizeof(*vfpframe), &vfpframe->size);
for (i = 0; i < 32; i++) {
- __put_user(env->vfp.regs[i], &vfpframe->ufp.fpregs[i]);
+ __put_user(float64_val(env->vfp.regs[i]), &vfpframe->ufp.fpregs[i]);
}
__put_user(vfp_get_fpscr(env), &vfpframe->ufp.fpscr);
__put_user(env->vfp.xregs[ARM_VFP_FPEXC], &vfpframe->ufp_exc.fpexc);
@@ -1588,7 +1588,7 @@ static abi_ulong *restore_sigframe_v2_vfp(CPUState *env, abi_ulong *regspace)
return 0;
}
for (i = 0; i < 32; i++) {
- __get_user(env->vfp.regs[i], &vfpframe->ufp.fpregs[i]);
+ __get_user(float64_val(env->vfp.regs[i]), &vfpframe->ufp.fpregs[i]);
}
__get_user(fpscr, &vfpframe->ufp.fpscr);
vfp_set_fpscr(env, fpscr);
--
1.7.1
^ permalink raw reply related
* [Qemu-devel] [PATCH 1/2] softfloat: Fix compilation failures with USE_SOFTFLOAT_STRUCT_TYPES
From: Peter Maydell @ 2011-02-10 13:59 UTC (permalink / raw)
To: qemu-devel; +Cc: patches
In-Reply-To: <1297346375-11461-1-git-send-email-peter.maydell@linaro.org>
Make softfloat compile with USE_SOFTFLOAT_STRUCT_TYPES defined, by
adding and using new macros const_float32() and const_float64() so
you can use array initializers in an array of float32/float64 whether
the types are bare or wrapped in the structs.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
fpu/softfloat.c | 30 +++++++++++++++---------------
fpu/softfloat.h | 4 ++++
2 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/fpu/softfloat.c b/fpu/softfloat.c
index 17842f4..8de887d 100644
--- a/fpu/softfloat.c
+++ b/fpu/softfloat.c
@@ -2172,21 +2172,21 @@ float32 float32_sqrt( float32 a STATUS_PARAM )
static const float64 float32_exp2_coefficients[15] =
{
- make_float64( 0x3ff0000000000000ll ), /* 1 */
- make_float64( 0x3fe0000000000000ll ), /* 2 */
- make_float64( 0x3fc5555555555555ll ), /* 3 */
- make_float64( 0x3fa5555555555555ll ), /* 4 */
- make_float64( 0x3f81111111111111ll ), /* 5 */
- make_float64( 0x3f56c16c16c16c17ll ), /* 6 */
- make_float64( 0x3f2a01a01a01a01all ), /* 7 */
- make_float64( 0x3efa01a01a01a01all ), /* 8 */
- make_float64( 0x3ec71de3a556c734ll ), /* 9 */
- make_float64( 0x3e927e4fb7789f5cll ), /* 10 */
- make_float64( 0x3e5ae64567f544e4ll ), /* 11 */
- make_float64( 0x3e21eed8eff8d898ll ), /* 12 */
- make_float64( 0x3de6124613a86d09ll ), /* 13 */
- make_float64( 0x3da93974a8c07c9dll ), /* 14 */
- make_float64( 0x3d6ae7f3e733b81fll ), /* 15 */
+ const_float64( 0x3ff0000000000000ll ), /* 1 */
+ const_float64( 0x3fe0000000000000ll ), /* 2 */
+ const_float64( 0x3fc5555555555555ll ), /* 3 */
+ const_float64( 0x3fa5555555555555ll ), /* 4 */
+ const_float64( 0x3f81111111111111ll ), /* 5 */
+ const_float64( 0x3f56c16c16c16c17ll ), /* 6 */
+ const_float64( 0x3f2a01a01a01a01all ), /* 7 */
+ const_float64( 0x3efa01a01a01a01all ), /* 8 */
+ const_float64( 0x3ec71de3a556c734ll ), /* 9 */
+ const_float64( 0x3e927e4fb7789f5cll ), /* 10 */
+ const_float64( 0x3e5ae64567f544e4ll ), /* 11 */
+ const_float64( 0x3e21eed8eff8d898ll ), /* 12 */
+ const_float64( 0x3de6124613a86d09ll ), /* 13 */
+ const_float64( 0x3da93974a8c07c9dll ), /* 14 */
+ const_float64( 0x3d6ae7f3e733b81fll ), /* 15 */
};
float32 float32_exp2( float32 a STATUS_PARAM )
diff --git a/fpu/softfloat.h b/fpu/softfloat.h
index 4a5345c..aaf6afc 100644
--- a/fpu/softfloat.h
+++ b/fpu/softfloat.h
@@ -125,11 +125,13 @@ typedef struct {
/* The cast ensures an error if the wrong type is passed. */
#define float32_val(x) (((float32)(x)).v)
#define make_float32(x) __extension__ ({ float32 f32_val = {x}; f32_val; })
+#define const_float32(x) { x }
typedef struct {
uint64_t v;
} float64;
#define float64_val(x) (((float64)(x)).v)
#define make_float64(x) __extension__ ({ float64 f64_val = {x}; f64_val; })
+#define const_float64(x) { x }
#else
typedef uint32_t float32;
typedef uint64_t float64;
@@ -137,6 +139,8 @@ typedef uint64_t float64;
#define float64_val(x) (x)
#define make_float32(x) (x)
#define make_float64(x) (x)
+#define const_float32(x) x
+#define const_float64(x) x
#endif
#ifdef FLOATX80
typedef struct {
--
1.7.1
^ permalink raw reply related
* [Qemu-devel] [PATCH 0/2] softfloat: fix USE_SOFTFLOAT_STRUCT_TYPES compile failures
From: Peter Maydell @ 2011-02-10 13:59 UTC (permalink / raw)
To: qemu-devel; +Cc: patches
This patchset fixes some compilation failures which happen if you try to
enable softfloat's USE_SOFTFLOAT_STRUCT_TYPES type-error-debugging switch.
This patchset leaves one error in float16_to_float32, because
that is fixed in passing by my half-precision patchset, and I
saw no point in deliberately creating a patch conflict.
I've only fixed the problems with core softfloat and the ARM targets;
maintainers of other targets can fix their platforms if they think it's
worth doing.
Peter Maydell (2):
softfloat: Fix compilation failures with USE_SOFTFLOAT_STRUCT_TYPES
linux-user/arm: fix compilation failures using softfloat's struct
types
fpu/softfloat.c | 30 +++++++++++++++---------------
fpu/softfloat.h | 4 ++++
linux-user/arm/nwfpe/fpa11_cpdt.c | 2 +-
linux-user/arm/nwfpe/fpopcode.c | 32 ++++++++++++++++----------------
linux-user/signal.c | 4 ++--
5 files changed, 38 insertions(+), 34 deletions(-)
^ permalink raw reply
* [PATCH 1/1] gatserver: Add ATS5 command feature
From: Olivier Guiter @ 2011-02-10 13:59 UTC (permalink / raw)
To: ofono
[-- Attachment #1: Type: text/plain, Size: 863 bytes --]
---
gatchat/gatserver.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/gatchat/gatserver.c b/gatchat/gatserver.c
index be9f79a..25b7ba4 100644
--- a/gatchat/gatserver.c
+++ b/gatchat/gatserver.c
@@ -796,6 +796,7 @@ static char *extract_line(GAtServer *p, struct ring_buffer *rbuf)
int line_length = 0;
gboolean in_string = FALSE;
char s3 = p->v250.s3;
+ char s5 = p->v250.s5;
char *line;
int i;
@@ -837,7 +838,11 @@ static char *extract_line(GAtServer *p, struct ring_buffer *rbuf)
if (*buf == '"')
in_string = !in_string;
- if ((*buf == ' ' || *buf == '\t') && in_string == FALSE)
+ if (*buf == s5) {
+ if (i != 0)
+ i -= 1;
+ }
+ else if ((*buf == ' ' || *buf == '\t') && in_string == FALSE)
; /* Skip */
else if (*buf != s3)
line[i++] = *buf;
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 1/2] atmel/macb: fix device name when SOFT/HARD_IRQ enabled
From: Sergei Shtylyov @ 2011-02-10 13:58 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: Sergei Shtylyov, linux-arm-kernel, netdev, Nicolas Ferre,
Paul Chavent
In-Reply-To: <20110209144411.GB11255@game.jcrosoft.org>
Hello.
On 09-02-2011 17:44, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>> From: Paul Chavent<paul.chavent@fnac.net>
>>> When listing processes on a system with SOFT/HARD_IRQ enabled,
>>> the name of the ethernet device is [irq/eth%d] (instead of [irq/eth0] for example).
>>> This patch call the request_irq function after having initialized the name of the device.
>>> Signed-off-by: Paul Chavent<paul.chavent@fnac.net>
>>> Signed-off-by: Nicolas Ferre<nicolas.ferre@atmel.com>
>>> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD<plagnioj@jcrosoft.com>
>> [...]
>>> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
>>> index f69e73e..d642e08 100644
>>> --- a/drivers/net/macb.c
>>> +++ b/drivers/net/macb.c
>> [...]
>>> @@ -1219,13 +1209,23 @@ static int __init macb_probe(struct platform_device *pdev)
>>> err = register_netdev(dev);
>>> if (err) {
>>> dev_err(&pdev->dev, "Cannot register net device, aborting.\n");
>>> - goto err_out_free_irq;
>>> + goto err_out_iounmap;
>>> }
>>>
>>> - if (macb_mii_init(bp) != 0) {
>>> + dev->irq = platform_get_irq(pdev, 0);
>> platform_get_irq() can fail...
> request_irq will fail too so do we really need to check it?
You then will get the following printed:
macb: Unable to request IRQ -6 (error -22)
If this is acceptable, then platfrom_get_irq()'s result can be ignored indeed.
>>> + err = request_irq(dev->irq, macb_interrupt, IRQF_SAMPLE_RANDOM,
>>> + dev->name, dev);
> Best Regards,
> J.
WBR, Sergei
^ permalink raw reply
* [PATCH] x86: suppress HPET broadcast initialization in the presence of ARAT
From: Jan Beulich @ 2011-02-10 13:58 UTC (permalink / raw)
To: xen-devel@lists.xensource.com
[-- Attachment #1: Type: text/plain, Size: 731 bytes --]
This follows Linux commit 39fe05e58c5e448601ce46e6b03900d5bf31c4b0,
noticing that all this setup is pointless when ARAT support is there,
and knowing that on SLED11's native kernel it has actually caused S3
resume issues.
A question would be whether HPET legacy interrupts should be forced
off in this case (rather than leaving whatever came from firmware).
Signed-off-by: Jan Beulich <jbeulich@novell.com>
--- a/xen/arch/x86/hpet.c
+++ b/xen/arch/x86/hpet.c
@@ -557,6 +557,9 @@ void hpet_broadcast_init(void)
u32 hpet_id, cfg;
int i;
+ if ( boot_cpu_has(X86_FEATURE_ARAT) )
+ return;
+
if ( irq_channel == NULL )
{
irq_channel = xmalloc_array(int, nr_irqs);
[-- Attachment #2: x86-arat-no-hpet-irq.patch --]
[-- Type: text/plain, Size: 725 bytes --]
This follows Linux commit 39fe05e58c5e448601ce46e6b03900d5bf31c4b0,
noticing that all this setup is pointless when ARAT support is there,
and knowing that on SLED11's native kernel it has actually caused S3
resume issues.
A question would be whether HPET legacy interrupts should be forced
off in this case (rather than leaving whatever came from firmware).
Signed-off-by: Jan Beulich <jbeulich@novell.com>
--- a/xen/arch/x86/hpet.c
+++ b/xen/arch/x86/hpet.c
@@ -557,6 +557,9 @@ void hpet_broadcast_init(void)
u32 hpet_id, cfg;
int i;
+ if ( boot_cpu_has(X86_FEATURE_ARAT) )
+ return;
+
if ( irq_channel == NULL )
{
irq_channel = xmalloc_array(int, nr_irqs);
[-- 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
* [PATCH 1/2] atmel/macb: fix device name when SOFT/HARD_IRQ enabled
From: Sergei Shtylyov @ 2011-02-10 13:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110209144411.GB11255@game.jcrosoft.org>
Hello.
On 09-02-2011 17:44, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>> From: Paul Chavent<paul.chavent@fnac.net>
>>> When listing processes on a system with SOFT/HARD_IRQ enabled,
>>> the name of the ethernet device is [irq/eth%d] (instead of [irq/eth0] for example).
>>> This patch call the request_irq function after having initialized the name of the device.
>>> Signed-off-by: Paul Chavent<paul.chavent@fnac.net>
>>> Signed-off-by: Nicolas Ferre<nicolas.ferre@atmel.com>
>>> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD<plagnioj@jcrosoft.com>
>> [...]
>>> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
>>> index f69e73e..d642e08 100644
>>> --- a/drivers/net/macb.c
>>> +++ b/drivers/net/macb.c
>> [...]
>>> @@ -1219,13 +1209,23 @@ static int __init macb_probe(struct platform_device *pdev)
>>> err = register_netdev(dev);
>>> if (err) {
>>> dev_err(&pdev->dev, "Cannot register net device, aborting.\n");
>>> - goto err_out_free_irq;
>>> + goto err_out_iounmap;
>>> }
>>>
>>> - if (macb_mii_init(bp) != 0) {
>>> + dev->irq = platform_get_irq(pdev, 0);
>> platform_get_irq() can fail...
> request_irq will fail too so do we really need to check it?
You then will get the following printed:
macb: Unable to request IRQ -6 (error -22)
If this is acceptable, then platfrom_get_irq()'s result can be ignored indeed.
>>> + err = request_irq(dev->irq, macb_interrupt, IRQF_SAMPLE_RANDOM,
>>> + dev->name, dev);
> Best Regards,
> J.
WBR, Sergei
^ permalink raw reply
* [PATCH, TopGit] tg-annihilate: Pass --no-verify when committing.
From: Thomas Schwinge @ 2011-02-10 13:39 UTC (permalink / raw)
To: ceder, u.kleine-koenig, git; +Cc: Thomas Schwinge
This is needed in order to inhibit TopGit's pre-commit hook to run,
which would bark upon missing .top* files.
---
Hallo!
(Yeah, I'm still using TopGit for some things.) I needed the following
patch to make tg annihilate work if the base is a non-TopGit branch. Is
this the correct approach?
Grüße,
Thomas
tg-annihilate.sh | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/tg-annihilate.sh b/tg-annihilate.sh
index 219b8fe..89d192c 100644
--- a/tg-annihilate.sh
+++ b/tg-annihilate.sh
@@ -34,7 +34,9 @@ baserev="$(git rev-parse --verify "refs/top-bases/$name" 2>/dev/null)" ||
## Annihilate
mb="$(git merge-base "refs/top-bases/$name" "$name")"
git read-tree "$mb^{tree}"
-git commit -m"TopGit branch $name annihilated."
+# Need to pass --no-verify in order to inhibit TopGit's pre-commit hook to run,
+# which would bark upon missing .top* files.
+git commit --no-verify -m"TopGit branch $name annihilated."
info 'If you have shared your work, you might want to run `tg push` now.'
info 'Then you probably want to switch to another branch.'
--
1.7.1
^ permalink raw reply related
* Re: [B.A.T.M.A.N.] [PATCH 2/7] batman-adv: Correct rcu refcounting for softif_neigh
From: Marek Lindner @ 2011-02-10 13:57 UTC (permalink / raw)
To: The list for a Better Approach To Mobile Ad-hoc Networking
In-Reply-To: <20110210124544.GC13038@Sellars>
On Thursday 10 February 2011 13:45:44 Linus Lüssing wrote:
> > - goto found;
> > + goto out;
> >
> > }
>
> Hmm, we could do a rcu_read_unlock() here, already, I think. Would
> it be better to do so, keeping the rcu grace period as small as
> possible?
Can you be more specific where "here" is ? Instead of the "goto out" ?
> The rest of the new atomic handling seems fine. Just two more
> things I noticed while reading the softif_neigh specific code:
> bat_priv->softif_neigh needs to be changed to a rcu-protected
> pointer.
Agreed.
> There's a race condition in softif_neigh_seq_print_text(), between
> the rcu_read_unlock() and rcu_read_lock() the number of
> softif_neigh's can have increased and there's no check for
> accidentally writing outside of the allocated buffer.
Also correct - are you going to send a patch ?
Regards,
Marek
^ permalink raw reply
* [GIT PULL] amd64_edac for .38-rc5
From: Borislav Petkov @ 2011-02-10 13:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Markus Trippelsdorf, edac-devel, LKML
Hi Linus,
please pull the below fix for ganged DCT mode.
Thanks.
The following changes since commit 100b33c8bd8a3235fd0b7948338d6cbb3db3c63d:
Linux 2.6.38-rc4 (2011-02-07 16:03:55 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git for-linus
Borislav Petkov (1):
amd64_edac: Fix DIMMs per DCTs output
drivers/edac/amd64_edac.c | 28 ++++++++--------------------
1 files changed, 8 insertions(+), 20 deletions(-)
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632
^ permalink raw reply
* [PATCH] x86: tighten conditions under which writing certain MSRs is permitted
From: Jan Beulich @ 2011-02-10 13:57 UTC (permalink / raw)
To: xen-devel@lists.xensource.com
[-- Attachment #1: Type: text/plain, Size: 2412 bytes --]
MSRs that control physical CPU aspects generally are pointless (and
possibly dangerous) to be written when the writer isn't sufficiently
aware that it's running virtualized.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -2282,7 +2282,7 @@ static int emulate_privileged_op(struct
if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD ||
boot_cpu_data.x86 < 0x10 || boot_cpu_data.x86 > 0x17 )
goto fail;
- if ( !IS_PRIV(v->domain) )
+ if ( !IS_PRIV(v->domain) || !is_pinned_vcpu(v) )
break;
if ( (rdmsr_safe(MSR_AMD64_NB_CFG, val) != 0) ||
(eax != (uint32_t)val) ||
@@ -2295,7 +2295,7 @@ static int emulate_privileged_op(struct
if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD ||
boot_cpu_data.x86 < 0x10 || boot_cpu_data.x86 > 0x17 )
goto fail;
- if ( !IS_PRIV(v->domain) )
+ if ( !IS_PRIV(v->domain) || !is_pinned_vcpu(v) )
break;
if ( (rdmsr_safe(MSR_FAM10H_MMIO_CONF_BASE, val) != 0) )
goto fail;
@@ -2317,6 +2317,8 @@ static int emulate_privileged_op(struct
case MSR_IA32_UCODE_REV:
if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
goto fail;
+ if ( !IS_PRIV(v->domain) || !is_pinned_vcpu(v) )
+ break;
if ( rdmsr_safe(regs->ecx, val) )
goto fail;
if ( msr_content )
@@ -2324,7 +2326,7 @@ static int emulate_privileged_op(struct
break;
case MSR_IA32_MISC_ENABLE:
if ( rdmsr_safe(regs->ecx, val) )
- goto invalid;
+ goto fail;
val = guest_misc_enable(val);
if ( msr_content != val )
goto invalid;
@@ -2351,7 +2353,7 @@ static int emulate_privileged_op(struct
case MSR_IA32_ENERGY_PERF_BIAS:
if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
goto fail;
- if ( (v->domain->domain_id != 0) || !is_pinned_vcpu(v) )
+ if ( !IS_PRIV(v->domain) || !is_pinned_vcpu(v) )
break;
if ( wrmsr_safe(regs->ecx, msr_content) != 0 )
goto fail;
[-- Attachment #2: x86-adjust-guest-wrmsr.patch --]
[-- Type: text/plain, Size: 2406 bytes --]
MSRs that control physical CPU aspects generally are pointless (and
possibly dangerous) to be written when the writer isn't sufficiently
aware that it's running virtualized.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -2282,7 +2282,7 @@ static int emulate_privileged_op(struct
if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD ||
boot_cpu_data.x86 < 0x10 || boot_cpu_data.x86 > 0x17 )
goto fail;
- if ( !IS_PRIV(v->domain) )
+ if ( !IS_PRIV(v->domain) || !is_pinned_vcpu(v) )
break;
if ( (rdmsr_safe(MSR_AMD64_NB_CFG, val) != 0) ||
(eax != (uint32_t)val) ||
@@ -2295,7 +2295,7 @@ static int emulate_privileged_op(struct
if ( boot_cpu_data.x86_vendor != X86_VENDOR_AMD ||
boot_cpu_data.x86 < 0x10 || boot_cpu_data.x86 > 0x17 )
goto fail;
- if ( !IS_PRIV(v->domain) )
+ if ( !IS_PRIV(v->domain) || !is_pinned_vcpu(v) )
break;
if ( (rdmsr_safe(MSR_FAM10H_MMIO_CONF_BASE, val) != 0) )
goto fail;
@@ -2317,6 +2317,8 @@ static int emulate_privileged_op(struct
case MSR_IA32_UCODE_REV:
if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
goto fail;
+ if ( !IS_PRIV(v->domain) || !is_pinned_vcpu(v) )
+ break;
if ( rdmsr_safe(regs->ecx, val) )
goto fail;
if ( msr_content )
@@ -2324,7 +2326,7 @@ static int emulate_privileged_op(struct
break;
case MSR_IA32_MISC_ENABLE:
if ( rdmsr_safe(regs->ecx, val) )
- goto invalid;
+ goto fail;
val = guest_misc_enable(val);
if ( msr_content != val )
goto invalid;
@@ -2351,7 +2353,7 @@ static int emulate_privileged_op(struct
case MSR_IA32_ENERGY_PERF_BIAS:
if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
goto fail;
- if ( (v->domain->domain_id != 0) || !is_pinned_vcpu(v) )
+ if ( !IS_PRIV(v->domain) || !is_pinned_vcpu(v) )
break;
if ( wrmsr_safe(regs->ecx, msr_content) != 0 )
goto fail;
[-- 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
* Re: [PATCH OF 07/14] of: move of_irq_map_pci() into generic code
From: Michal Simek @ 2011-02-10 13:57 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: linux-kernel, sodaville, x86, devicetree-discuss,
Sebastian Andrzej Siewior, Benjamin Herrenschmidt
In-Reply-To: <1295843342-1122-8-git-send-email-bigeasy@linutronix.de>
Sebastian Andrzej Siewior wrote:
> From: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
>
> There is a tiny difference between PPC32 and PPC64. Microblaze uses the
> PPC32 variant.
>
> Cc: devicetree-discuss@lists.ozlabs.org
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
> ---
> arch/microblaze/include/asm/pci-bridge.h | 12 ++++
> arch/microblaze/include/asm/prom.h | 15 -----
> arch/microblaze/kernel/prom_parse.c | 77 ---------------------------
> arch/microblaze/pci/pci-common.c | 1 +
Please always CC me for Microblaze changes. I want to at least compile it.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
^ permalink raw reply
* Re: different access rights for oe branches?
From: Steffen Sledz @ 2011-02-10 13:55 UTC (permalink / raw)
To: openembedded-devel; +Cc: Chris Larson
In-Reply-To: <AANLkTimEYm1sDsLob7rwkZy8GshO2KxihZAQBm4azB5e@mail.gmail.com>
Am 10.02.2011 14:48, schrieb Chris Larson:
> On Thu, Feb 10, 2011 at 6:34 AM, Steffen Sledz <sledz@dresearch.de> wrote:
>> We like to create a branch specific for our hipox machine.
>>
>> Is it possible to define access rights different to the dev-branch here?
>>
>> We would like to give write access to some of our developers which do not have/need write access do dev. In opposite it would be nice to limit the write access to these maintainers.
>
> We use gitolite now, which can indeed exert control over branch access
> for the users, afaik.
Fine. :)
Who can setup these rights?
Steffen
--
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sledz@DResearch.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058
^ permalink raw reply
* [PATCH 4/4] FIX: Add raid5 to raid0 case to analyse_change()
From: Adam Kwolek @ 2011-02-10 13:56 UTC (permalink / raw)
To: neilb; +Cc: linux-raid, dan.j.williams, ed.ciechanowski, wojciech.neubauer
In-Reply-To: <20110210134710.9276.91430.stgit@gklab-128-013.igk.intel.com>
Transition raid5 to raid0 was not covered in analyse_change()
Missing code added.
Signed-off-by: Adam Kwolek <adam.kwolek@intel.com>
---
Grow.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/Grow.c b/Grow.c
index 08fc258..b04faf1 100644
--- a/Grow.c
+++ b/Grow.c
@@ -1056,6 +1056,14 @@ char *analyse_change(struct mdinfo *info, struct reshape *re)
info->array.layout = ALGORITHM_PARITY_N;
case 5:
switch (info->new_level) {
+ case 0:
+ re->level = 5;
+ info->delta_disks = 0;
+ re->before.data_disks = info->array.raid_disks - 1;
+ re->before.layout = info->array.layout;
+ re->after.data_disks = info->array.raid_disks;
+ re->after.layout = 0;
+ break;
case 4:
re->level = info->array.level;
re->before.data_disks = info->array.raid_disks - 1;
^ permalink raw reply related
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.