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

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

Today's topics:

* sound/soc: use .dev.of_node instead of .node in struct of_device - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/2014a315f2e95e8a?hl=en
* microblaze: Add a missing single quote to make 'make help' happy - 2
messages, 2 authors
http://groups.google.com/group/linux.kernel/t/e25bc8ccc2e67b1f?hl=en
* microblaze: Fix Makefile to delete build generated files - 2 messages, 2
authors
http://groups.google.com/group/linux.kernel/t/07711f1de78d6181?hl=en
* Fix AES-NI CTR optimization compiling failure with gas 2.16.1 - 5 messages,
2 authors
http://groups.google.com/group/linux.kernel/t/e7f3de406b57c44d?hl=en
* RAID + LUKS + LVM performance - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/43ac9c2556338695?hl=en
* ST SPEAr: Added clock framework for SPEAr platform and machines - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/ce805d5c50983fd8?hl=en
* Possible bug in eeepc-laptop.c - EeePC 900 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/684e290393017980?hl=en
* x86/kvm: Show guest system/user cputime in cpustat - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f85ba99e07cdffa5?hl=en
* Linux wireless GSoC 2010 project ideas - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/09f2b94c7080815d?hl=en
* 2.6.34-rc1: rcu lockdep bug? - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/20ae452eb2399ce9?hl=en
* bit errors on spitz - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/32584eab7e27d325?hl=en
* Avoid the use of congestion_wait under zone pressure - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/65204523a890609a?hl=en
* MFD fixes for 2.6.34 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/bbf1296332f5c01a?hl=en
* V4L/DVB: mx1-camera: compile fix - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/a97df7cb32a1bed5?hl=en
* cpuset: alloc nodemask_t at heap not stack - fix - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/81da15ed0a3dc653?hl=en
* cpuset: fix the problem that cpuset_mem_spread_node() returns an offline
node - fix - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/54b73e7c0a319b73?hl=en
* x86: irq_desc->chip_data is always correct whether or not SPARSE_IRQ is
enabled. - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/8d79051b75e0b2aa?hl=en

==============================================================================
TOPIC: sound/soc: use .dev.of_node instead of .node in struct of_device
http://groups.google.com/group/linux.kernel/t/2014a315f2e95e8a?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Mar 12 2010 12:30 am
From: Jean Delvare

On Thu, 11 Mar 2010 14:22:37 -0700, Grant Likely wrote:
> On Thu, Mar 11, 2010 at 12:34 PM, Mark Brown
> <broonie@opensource.wolfsonmicro.com> wrote:
> > On Thu, Mar 11, 2010 at 11:06:50AM -0700, Grant Likely wrote:
> >> .node is being removed
> >>
> >> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> >
> > Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> >
> > but please ensure that Liam and especially Timur also check this (both
> > CCed).
> >
> > For enormous patch serieses like this it's really nice if you can ensure
> > that each person is only CCed on the patches that they need to review.
> > Much less stuff in the inbox.
>
> Yeah, sorry about that (and to everyone receiving this thread, I'm
> really sorry. I won't do it again). I've already been yelled at for
> that. What happened is that on a previous series I was yelled at for
> not sending all patches to everyone (so that the patches could be
> reviewed in context). So, naturally, I made sure to include everyone
> on the whole series this time.... doh.
>
> Next time I post I'll constrain it to small chunks.

A good compromise IMHO is to send only the pieces they really have to
see and ack to each person, and provide a pointer to somewhere the full
series can be seen and downloaded for the interested.

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

==============================================================================
TOPIC: microblaze: Add a missing single quote to make 'make help' happy
http://groups.google.com/group/linux.kernel/t/e25bc8ccc2e67b1f?hl=en
==============================================================================

== 1 of 2 ==
Date: Fri, Mar 12 2010 12:40 am
From: Arun Bhanu

'make ARCH=microblaze help' fails with the following error due to a
missing single quote.

/bin/sh: -c: line 0: unexpected EOF while looking for matching `''
/bin/sh: -c: line 1: syntax error: unexpected end of file
make: *** [help] Error 2

Signed-off-by: Arun Bhanu <arun@bhanu.net>
---
arch/microblaze/Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/microblaze/Makefile b/arch/microblaze/Makefile
index d2d6cfc..f49d8e6 100644
--- a/arch/microblaze/Makefile
+++ b/arch/microblaze/Makefile
@@ -83,7 +83,7 @@ define archhelp
echo '* linux.bin - Create raw binary'
echo ' linux.bin.gz - Create compressed raw binary'
echo ' simpleImage.<dt> - ELF image with $(arch)/boot/dts/<dt>.dts linked in'
- echo ' - stripped elf with fdt blob
+ echo ' - stripped elf with fdt blob'
echo ' simpleImage.<dt>.unstrip - full ELF image with fdt blob'
echo ' *_defconfig - Select default config from arch/microblaze/configs'
echo ''
--
1.6.2.5

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

== 2 of 2 ==
Date: Fri, Mar 12 2010 12:50 am
From: Michal Simek

Arun Bhanu wrote:
> 'make ARCH=microblaze help' fails with the following error due to a
> missing single quote.
>
> /bin/sh: -c: line 0: unexpected EOF while looking for matching `''
> /bin/sh: -c: line 1: syntax error: unexpected end of file
> make: *** [help] Error 2
>
> Signed-off-by: Arun Bhanu <arun@bhanu.net>

Added to next branch.

Thanks,
Michal

> ---
> arch/microblaze/Makefile | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/microblaze/Makefile b/arch/microblaze/Makefile
> index d2d6cfc..f49d8e6 100644
> --- a/arch/microblaze/Makefile
> +++ b/arch/microblaze/Makefile
> @@ -83,7 +83,7 @@ define archhelp
> echo '* linux.bin - Create raw binary'
> echo ' linux.bin.gz - Create compressed raw binary'
> echo ' simpleImage.<dt> - ELF image with $(arch)/boot/dts/<dt>.dts linked in'
> - echo ' - stripped elf with fdt blob
> + echo ' - stripped elf with fdt blob'
> echo ' simpleImage.<dt>.unstrip - full ELF image with fdt blob'
> echo ' *_defconfig - Select default config from arch/microblaze/configs'
> echo ''

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

==============================================================================
TOPIC: microblaze: Fix Makefile to delete build generated files
http://groups.google.com/group/linux.kernel/t/07711f1de78d6181?hl=en
==============================================================================

== 1 of 2 ==
Date: Fri, Mar 12 2010 12:40 am
From: Arun Bhanu

'make mrproper' does not to delete the following build generated files:
arch/microblaze/boot/linux.bin.ub
arch/microblaze/boot/simpleImage.system
arch/microblaze/boot/simpleImage.system.ub

Fix the Makefile to delete these build generated files.

Signed-off-by: Arun Bhanu <arun@bhanu.net>
---
arch/microblaze/boot/Makefile | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/microblaze/boot/Makefile b/arch/microblaze/boot/Makefile
index 902cf98..73a3263 100644
--- a/arch/microblaze/boot/Makefile
+++ b/arch/microblaze/boot/Makefile
@@ -62,6 +62,6 @@ quiet_cmd_dtc = DTC $@
$(obj)/%.dtb: $(dtstree)/%.dts FORCE
$(call if_changed,dtc)

-clean-kernel += linux.bin linux.bin.gz simpleImage.*
+clean-kernel += linux.bin linux.bin.gz

-clean-files += *.dtb simpleImage.*.unstrip
+clean-files += *.dtb *.ub simpleImage.*
--
1.6.2.5

== 2 of 2 ==
Date: Fri, Mar 12 2010 1:00 am
From: Michal Simek

Arun Bhanu wrote:
> 'make mrproper' does not to delete the following build generated files:
> arch/microblaze/boot/linux.bin.ub
> arch/microblaze/boot/simpleImage.system
> arch/microblaze/boot/simpleImage.system.ub
>
> Fix the Makefile to delete these build generated files.

The problem is that if you run make clean it will delete all simpleImage
files too. The best will be just delete them if you run make mrproper as
you wrote above. Make clean should keep them or just remove .unstrip
because of size.

Michal

>
> Signed-off-by: Arun Bhanu <arun@bhanu.net>
> ---
> arch/microblaze/boot/Makefile | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/microblaze/boot/Makefile b/arch/microblaze/boot/Makefile
> index 902cf98..73a3263 100644
> --- a/arch/microblaze/boot/Makefile
> +++ b/arch/microblaze/boot/Makefile
> @@ -62,6 +62,6 @@ quiet_cmd_dtc = DTC $@
> $(obj)/%.dtb: $(dtstree)/%.dts FORCE
> $(call if_changed,dtc)
>
> -clean-kernel += linux.bin linux.bin.gz simpleImage.*
> +clean-kernel += linux.bin linux.bin.gz
>
> -clean-files += *.dtb simpleImage.*.unstrip
> +clean-files += *.dtb *.ub simpleImage.*

==============================================================================
TOPIC: Fix AES-NI CTR optimization compiling failure with gas 2.16.1
http://groups.google.com/group/linux.kernel/t/e7f3de406b57c44d?hl=en
==============================================================================

== 1 of 5 ==
Date: Fri, Mar 12 2010 12:40 am
From: Avi Kivity

On 03/12/2010 09:01 AM, Huang Ying wrote:
> Andrew Morton reported that AES-NI CTR optimization failed to compile
> with gas 2.16.1, the error message is as follow:
>
> arch/x86/crypto/aesni-intel_asm.S: Assembler messages:
> arch/x86/crypto/aesni-intel_asm.S:752: Error: suffix or operands invalid for `movq'
> arch/x86/crypto/aesni-intel_asm.S:753: Error: suffix or operands invalid for `movq'
>
> To fix this, a gas macro is defined to assemble movq with 64bit
> general purpose registers and XMM registers. The macro will generate
> the raw .byte sequence for needed instructions.
>
>

Eventually you'll port the entire assembler into macros, as instructions
are introduced more frequently that people upgrade their assemblers.
Maybe we should disable the new features and warn people (and distros)
to upgrade their tools instead.

--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

== 2 of 5 ==
Date: Fri, Mar 12 2010 12:50 am
From: Avi Kivity

On 03/12/2010 10:42 AM, David Miller wrote:
> From: Avi Kivity<avi@redhat.com>
> Date: Fri, 12 Mar 2010 10:37:33 +0200
>
>
>> Eventually you'll port the entire assembler into macros, as
>> instructions are introduced more frequently that people upgrade their
>> assemblers. Maybe we should disable the new features and warn people
>> (and distros) to upgrade their tools instead.
>>
> I totally and completely disagree.
>
> It would have taken more than a year to get Niagara cpu support out to
> people if I had done what you are suggesting.
>

Strange, that people can install a new kernel, but not a new assembler.

> And here we're talking about one instruction in one specialized case
> in a very piece of crypto module assembler.
>

If it were one place, I'd agree, but there are more. kvm for example
also uses .byte instead of the actual instructions.

--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

== 3 of 5 ==
Date: Fri, Mar 12 2010 12:50 am
From: David Miller

From: Avi Kivity <avi@redhat.com>
Date: Fri, 12 Mar 2010 10:37:33 +0200

> Eventually you'll port the entire assembler into macros, as
> instructions are introduced more frequently that people upgrade their
> assemblers. Maybe we should disable the new features and warn people
> (and distros) to upgrade their tools instead.

I totally and completely disagree.

It would have taken more than a year to get Niagara cpu support out to
people if I had done what you are suggesting.

And here we're talking about one instruction in one specialized case
in a very piece of crypto module assembler.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 4 of 5 ==
Date: Fri, Mar 12 2010 1:00 am
From: David Miller

From: Avi Kivity <avi@redhat.com>
Date: Fri, 12 Mar 2010 10:44:58 +0200

> Strange, that people can install a new kernel, but not a new
> assembler.

Someone shouldn't have to upgrade their tools to build the
kernel.

And we work very hard to make sure this is the case except
in the most unavoidable situations.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 5 of 5 ==
Date: Fri, Mar 12 2010 1:40 am
From: Avi Kivity

On 03/12/2010 10:50 AM, David Miller wrote:
> From: Avi Kivity<avi@redhat.com>
> Date: Fri, 12 Mar 2010 10:44:58 +0200
>
>
>> Strange, that people can install a new kernel, but not a new
>> assembler.
>>
> Someone shouldn't have to upgrade their tools to build the
> kernel.
>

The kernel would still build, just without the AES-NI CTR optimization
(or kvm).

> And we work very hard to make sure this is the case except
> in the most unavoidable situations.
>

Why so hard? It has a cost. The user can certainly 'make
AS=~/new-binutils/bin/gas' and it wouldn't even affect the rest of their
system.

tools/as/ anyone?

--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

==============================================================================
TOPIC: RAID + LUKS + LVM performance
http://groups.google.com/group/linux.kernel/t/43ac9c2556338695?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Mar 12 2010 12:50 am
From: Mathias Buren

Matthias Schniedermeyer <ms@citd.de> wrote on 2010-03-11 17:36:04:

> Re: RAID + LUKS + LVM performance
>
> Matthias Schniedermeyer
>
> to:
>
> Mathias Buren
>
> 2010-03-11 17:39
>
> Cc:
>
> linux-kernel
>
> On 11.03.2010 13:08, Mathias Buren wrote:
> >
> > Hi,
> >
> > (please cc me as I'm not subscribed)
> >
> > I've a friend who's going to set up a fileserver consisting of 8x 1.5TB
> > HDDs, an 8-port PCI-E RAID card (Areca ARC-1220 @
> > http://www.areca.com.tw/products/pcie.htm ) etc.
> > The plan is create a RAID5 array spanning all the disks, then create 4
> > partitions. These 4 partitions would be encrypted using LUKS (Twofish
or
> > AES256).
> > These 4 encrypted partition would be set up in RAID0 using Linux'
software
> > (mdadm), then LVM would be used on top of that (one big PV, one big VG
and
> > a big LV or so).
> >
> > The reason for this is that kcryptd is not multithreaded (afaik). By
having
> > 4 encrypted partitions, then md0 on top of them, I'm forcing 4 kcryptd
> > processes to run on all four cpu cores whenever something is written to
the
> > disks, which should improve (encryption) performance.
> >
> > Is this a good way of doing it, or is there a smarter way?
>
> The setup you describe would only work with SSDs. HDDs would seek
> themselves to death.
>
> The problem is the RAID-0 over the 4 partitions. At that point you would
> need, instead of the 4 partitions, something that is round-robin. So
> that the mapping of the (physical) blocks from the upper to the lower
> would be effectivly linear/unchanged.
>
> AFAIK something like that is (currently) not possible.
>
>
>
>
>
> Bis denn
>
> --
> Real Programmers consider "what you see is what you get" to be just as
> bad a concept in Text Editors as it is in women. No, the Real Programmer
> wants a "you asked for it, you got it" text editor -- complicated,
> cryptic, powerful, unforgiving, dangerous.
>

Hm. But I thought, since the hw RAID card does its own RAID5 thing on the
harddrives, that they wouldn't seek themselves do death. Perhaps they
would, anyway...

What's the best way to set this up then? Or will kcryptd be able to
encrypt/decrypt everything fast enough anyway (~>5-600MB/s I'd say)?

Mathias

==============================================================================
TOPIC: ST SPEAr: Added clock framework for SPEAr platform and machines
http://groups.google.com/group/linux.kernel/t/ce805d5c50983fd8?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Mar 12 2010 12:50 am
From: Linus Walleij

2010/3/11 Shiraz HASHIM <shiraz.hashim@st.com>:
> On 3/11/2010 12:30 PM, Linus Walleij wrote:
>> 2010/3/3 Viresh KUMAR <viresh.kumar@st.com>:
>> (...)
>>> + if (unlikely(clk->flags & RESET_TO_ENABLE))
>>> + val &= ~(1 << clk->en_reg_bit);
>>> + else
>>> + val |= 1 << clk->en_reg_bit;
>>> + writel(val, clk->en_reg);
>>
>> I don't understand one bit of this. (...)
>
> The intention to use RESET_TO_ENABLE flag is to generalize clock
> enable/disable across platforms.

I misread the entire thing, there was some bad parsing inside my head...
Sorry about this.

>> OMAP uses CPUfreq but that is really about the CPU. As it happens, all
>> their clk:s always change frequency at the same operating points as the
>> CPU. So they can have pre/post calls from CPUfreq in their code, but
>> this will not work with things like PrimeCells where other users of the cell
>> may not have operating points correlated with CPU operating points.
>>
>> (I'm not requesting you to solve this problem, more to be aware of it.)
>
> I think generally in embedded systems (at least in our case :) ) the CPU clock
> itself is not completly independent. It is generally tied with some system
> clock, which has an impact on bus and peripheral clocks. In that sense cpu freq
> would be a better mean to notify frequency change.
> In any case, clock framework don't intend to do it. It only need to reflect
> correct system state. Is this understanding correct?

Currently it's like that but I think clk really needs a frequency change
notification mechanism. I will have to deal with it some day I think :-/

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

==============================================================================
TOPIC: Possible bug in eeepc-laptop.c - EeePC 900
http://groups.google.com/group/linux.kernel/t/684e290393017980?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Mar 12 2010 1:00 am
From: Corentin Chary

On Thu, Mar 11, 2010 at 10:28 PM, Fabio Comolli <fabio.comolli@gmail.com> wrote:
> Hi.
>
> On Tue, Mar 9, 2010 at 11:58 PM, Fabio Comolli <fabio.comolli@gmail.com> wrote:
>> Hi.
>> I have an EeePC 900 running 2.6.34-rc1.
>>
>> If I boot it on AC the cpu runs at full speed, 900MHz; if I boot it on
>> battery it runs only at 630Mhz. Plugging / unplugging the AC does not
>> change the cpu frequency. Only a reboot can change the situation.
>>
>> I already tried to echo 0 or 1 to the
>> /sys/devices/platform/eeepc/cpufv file; no effects, even if the file
>> changes its value.
>>
>> This is not a regression from 2.6.33: this behavior is also present in
>> that version.
>>
>> Does this ring any bells? This is really annoying, especially when
>> trying to watch a movie on battery. Also 3D apps show a 30%
>> performance drop, as expected.
>>
>> Regards,
>> Fabio
>
> Well, it turns out that this is indeed a regression, but I don't know
> from which kernel version.
> I reverted (not cleanly) this patch:
>
> http://patchwork.kernel.org/patch/28591
>
> and now
>
> echo 1 > /sys/devices/platform/eeepc/cpufv
>
> enables the powersave mode and
>
> echo 0 > /sys/devices/platform/eeepc/cpufv
>
> enables the performance mode.
>
> Tested with the non-benchmark glxgears (275 frames/sec in powersave
> mode and 405 in performance mode) and stellarium (14 frames and 20
> frames).
>
> Regards,
> Fabio
>

Thanks for the report,
Could you try to add a quick printk to show the value stored in
set_acpi(CM_ASL_CPUFV, value); ?
And also, could you send the result of acpidump ?
Thanks,

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

==============================================================================
TOPIC: x86/kvm: Show guest system/user cputime in cpustat
http://groups.google.com/group/linux.kernel/t/f85ba99e07cdffa5?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Mar 12 2010 1:00 am
From: Qing He

On Thu, 2010-03-11 at 17:17 +0800, Sheng Yang wrote:
> On Thursday 11 March 2010 15:50:54 Avi Kivity wrote:
> > On 03/11/2010 09:46 AM, Sheng Yang wrote:
> > > On Thursday 11 March 2010 15:36:01 Avi Kivity wrote:
> > >> On 03/11/2010 09:20 AM, Sheng Yang wrote:
> > >>> Currently we can only get the cpu_stat of whole guest as one. This
> > >>> patch enhanced cpu_stat with more detail, has guest_system and
> > >>> guest_user cpu time statistics with a little overhead.
> > >>>
> > >>> Signed-off-by: Sheng Yang<sheng@linux.intel.com>
> > >>> ---
> > >>>
> > >>> This draft patch based on KVM upstream to show the idea. I would split
> > >>> it into more kernel friendly version later.
> > >>>
> > >>> The overhead is, the cost of get_cpl() after each exit from guest.
> > >>
> > >> This can be very expensive in the nested virtualization case, so I
> > >> wouldn't like this to be in normal paths. I think detailed profiling
> > >> like that can be left to 'perf kvm', which only has overhead if enabled
> > >> at runtime.
> > >
> > > Yes, that's my concern too(though nested vmcs/vmcb read already too
> > > expensive, they should be optimized...).
> >
> > Any ideas on how to do that? Perhaps use paravirt_ops to covert the
> > vmread into a memory read? We store the vmwrites in the vmcs anyway.
>
> When Qing(CCed) was working on nested VMX in the past, he found PV
> vmread/vmwrite indeed works well(it would write to the virtual vmcs so vmwrite
> can also benefit). Though compared to old machine(one our internal patch shows
> improve more than 5%), NHM get less benefit due to the reduced vmexit cost.
>

One of the hurdles to PVize vmread/vmwrite is the fact that the memory
layout of physical vmcs remains unknown. Of course it can use the custom
vmcs layout utilized by nested virtualization, but that looks a little weird,
since different nested virtualization implementation may create different
custom layout.

I once used another approach to partially accelerate the vmread/vmwrite
in nested virtualization case, which also gives good performance gain (around
7% on pre-nehalem, based on this, PV vmread/vmwrite had another 7%). That
is to make a shortcut to handle EXIT_REASON_VM{READ,WRITE}, without
even turning on the IF.

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

==============================================================================
TOPIC: Linux wireless GSoC 2010 project ideas
http://groups.google.com/group/linux.kernel/t/09f2b94c7080815d?hl=en
==============================================================================

== 1 of 2 ==
Date: Fri, Mar 12 2010 1:00 am
From: Till Kamppeter

Can someone post this project idea on the ideas list today (marking that
it comes from a student). This could support our application as
mentoring organization.

Till

On 03/09/2010 11:43 PM, Frederic Weisbecker wrote:
> On Fri, Jan 29, 2010 at 12:51:59AM +0100, Till Kamppeter wrote:
>> No problem for students to suggest topics. We are not restricted to
>> wireless in terms of kernel. We support kernel projects in general.
>>
>> Please give your suggestion as answer to this e-mail, doing "Reply to
>> all", as I am not a kernel export, the other participants of this thread
>> should have a look at the student's project ideas and help finding
>> mentors.
>>
>> Till
>
>
>
> Ok, I hope it's not too late.
> Here is one subject that I would like to apply for:
>
>
> = Improving tracing in perf events / ftrace =
>
>
> Using trace events under perf events is still a young feature
> and needs various improvements.
>
> - Syscall events can carry only raw values and addresses.
> We need to make them "aware" of strings and structures contents
> from userspace.
>
> - Make function / function graph tracers usable by perf
>
> - Optimize tracing fast-path
>
> - Improve perf tools to better handle trace events scalability
>
> - Provide new perf tools that exploit trace events (scheduler
> migration analysis, etc...)
>
> - Implement a per context excluding (eg: exclude irqs, exclude functions, etc...)
>
> - There are always things to do there.
>
>
> Of course, each of these elements require a lot of work,
> so not all of them can be done in two months, and some
> of them can be started already before the summer.
>
>

== 2 of 2 ==
Date: Fri, Mar 12 2010 1:40 am
From: Denis Silakov

Added this item to '2010 GSoC Kernel work' page:

https://www.linuxfoundation.org/collaborate/workgroups/gsoc/2010-gsoc-kernel-work

On 03/12/10 11:59, Till Kamppeter wrote:
> Can someone post this project idea on the ideas list today (marking that
> it comes from a student). This could support our application as
> mentoring organization.
>
> Till
>

--
Regards,
Denis.

==============================================================================
TOPIC: 2.6.34-rc1: rcu lockdep bug?
http://groups.google.com/group/linux.kernel/t/20ae452eb2399ce9?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Mar 12 2010 1:10 am
From: Américo Wang

On Fri, Mar 12, 2010 at 4:07 PM, David Miller <davem@davemloft.net> wrote:
> From: Américo Wang <xiyou.wangcong@gmail.com>
> Date: Fri, 12 Mar 2010 15:56:03 +0800
>
>> Ok, after decoding the lockdep output, it looks like that
>> netif_receive_skb() should call rcu_read_lock_bh() instead of rcu_read_lock()?
>> But I don't know if all callers of netif_receive_skb() are in softirq context.
>
> Normally, netif_receive_skb() is invoked from softirq context.
>
> However, via netpoll it can be invoked essentially from any context.
>
> But, when this happens, the networking receive path makes amends such
> that this works fine. That's what the netpoll_receive_skb() check in
> netif_receive_skb() is for. That check makes it bail out early if the
> call to netif_receive_skb() is via a netpoll invocation.
>

Oh, I see. This means we should call rcu_read_lock_bh() instead.
If Paul has no objections, I will send a patch for this.

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

==============================================================================
TOPIC: bit errors on spitz
http://groups.google.com/group/linux.kernel/t/32584eab7e27d325?hl=en
==============================================================================

== 1 of 2 ==
Date: Fri, Mar 12 2010 1:10 am
From: Stanislav Brabec

Andy Green wrote:
> On 03/11/10 15:42, Somebody in the thread at some point said:
> > Andy Green wrote:
> >
> >> I saw very similar failures for a long time on our iMX31 based device.
> >> Eventually I found a Freescale errata where the RAM inside the USB2
> >> macrocell started to make single bit errors below 1.38V Vcore; ours was
> >> 1.4V at that time but dipped on CPU load.
> >
> > Good tip. It seems that nobody ported driver for the voltage control
> > chip ISL6271 from 2.4 kernel, and bootloader probably does not set
> > correct values.

> Unless there's more to it in the way the zaurus using it that regulator
> isn't programmable digitally.

OOPS, I made a mistake and linked ISL6721 instead of ISL6271 there.
Now it is fixed:
http://www.penguin.cz/~utx/zaurus/datasheets/power/XScale/ISL6271A.pdf

This one has I2C. It is connected to GPIO 3 (PWR_SCL) and GPIO 4
(PWR_SDA).

It is visible between the black plastic and the large circular coil:
http://www.penguin.cz/~utx/zaurus/teardown#pcbt

> Reading about your CF Card WLAN related issues they suck down a good
> amount of power when their radio is up, I would definitely suggest
> monitoring with a 'scope the various rails (Vcore, RAM and whatever it
> is the CF Card is powered by) while putting it under load.

I guess that Zaurus has a good power design and that voltage should be
constant enough. CF has a dedicated step down (plus 2.8V power detector
(Why so low, if CF standard requres more?)), HDD has a dedicated step
up/down. USB has dedicated step up. Companion chips use dedicated 3.3V
step down. Audio uses dedicated linear regulator. CPU has several
dedicated step downs, CPU 3.3V uses step-up to 5V and then down to 3.3V
(which is shared only with IOPORT).

Nearest common point between CF card power and CPU power is the battery.

________________________________________________________________________

Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

== 2 of 2 ==
Date: Fri, Mar 12 2010 1:40 am
From: Andy Green

On 03/12/10 09:07, Somebody in the thread at some point said:

>> Unless there's more to it in the way the zaurus using it that regulator
>> isn't programmable digitally.
>
> OOPS, I made a mistake and linked ISL6721 instead of ISL6271 there.
> Now it is fixed:
> http://www.penguin.cz/~utx/zaurus/datasheets/power/XScale/ISL6271A.pdf
>
> This one has I2C. It is connected to GPIO 3 (PWR_SCL) and GPIO 4
> (PWR_SDA).

Thanks... that defaults to 1.3V on Vcore if you don't touch it. I guess
confirm on the CPU datasheet that it's OK for your selected CPU clock speed.

> I guess that Zaurus has a good power design and that voltage should be
> constant enough. CF has a dedicated step down (plus 2.8V power detector

In that case is the PXA CF driver PIO? Then it can be the same load on
Vcore issue in disguise.

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

==============================================================================
TOPIC: Avoid the use of congestion_wait under zone pressure
http://groups.google.com/group/linux.kernel/t/65204523a890609a?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Mar 12 2010 1:20 am
From: Mel Gorman

On Thu, Mar 11, 2010 at 03:41:24PM -0800, Andrew Morton wrote:
> On Mon, 8 Mar 2010 11:48:20 +0000
> Mel Gorman <mel@csn.ul.ie> wrote:
>
> > Under memory pressure, the page allocator and kswapd can go to sleep using
> > congestion_wait(). In two of these cases, it may not be the appropriate
> > action as congestion may not be the problem.
>
> clear_bdi_congested() is called each time a write completes and the
> queue is below the congestion threshold.
>

Where you appear to get a kicking is if you want on "congestion" but no
writes are involved. In that case you potentially sleep for the whole timeout
waiting on an event that is not going to occur.

> So if the page allocator or kswapd call congestion_wait() against a
> non-congested queue, they'll wake up on the very next write completion.
>
> Hence the above-quoted claim seems to me to be a significant mis-analysis and
> perhaps explains why the patchset didn't seem to help anything?
>

--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: MFD fixes for 2.6.34
http://groups.google.com/group/linux.kernel/t/bbf1296332f5c01a?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Mar 12 2010 1:20 am
From: Samuel Ortiz

Hi Linus,

I have a couple of MFD fixes, fixing the sm501 region requested size and
the MFD Kconfig for genirq dependent drivers.

Thanks in advance for pulling.

The following changes since commit 522dba7134d6b2e5821d3457f7941ec34f668e6d:
Linus Torvalds (1):
Merge branch 'for-linus' of git://git.kernel.org/.../jbarnes/pci-2.6

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6.git for-linus

Geert Uytterhoeven (1):
mfd: Several MFD drivers should depend on GENERIC_HARDIRQS

Samuel Ortiz (1):
mfd: Fix sm501 requested region size

drivers/mfd/Kconfig | 9 +++++----
drivers/mfd/sm501.c | 4 ++--
2 files changed, 7 insertions(+), 6 deletions(-)

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

==============================================================================
TOPIC: V4L/DVB: mx1-camera: compile fix
http://groups.google.com/group/linux.kernel/t/a97df7cb32a1bed5?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Mar 12 2010 1:30 am
From: Guennadi Liakhovetski

Hi Uwe

On Fri, 5 Mar 2010, Uwe Kleine-König wrote:

> This is a regression of
>
> 7d58289 (mx1: prefix SOC specific defines with MX1_ and deprecate old names)
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> drivers/media/video/mx1_camera.c | 12 +++++++-----
> 1 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/video/mx1_camera.c b/drivers/media/video/mx1_camera.c
> index 2ba14fb..29c2833 100644
> --- a/drivers/media/video/mx1_camera.c
> +++ b/drivers/media/video/mx1_camera.c
> @@ -45,11 +45,13 @@
> #include <mach/hardware.h>
> #include <mach/mx1_camera.h>
>
> +#define __DMAREG(offset) (MX1_IO_ADDRESS(MX1_DMA_BASE_ADDR) + offset)
> +

Well, I think, Sascha is right, we have to fix
arch/arm/plat-mxc/include/mach/dma-mx1-mx2.h, because that's what actually
got broken. The line

#define DMA_BASE IO_ADDRESS(DMA_BASE_ADDR)

in it is no longer valid, right? So, we have to either remove it, or fix
it, if we think, that other drivers might start using it. And even if we
decide to remove it from the header and implement here, wouldn't it be
better to choose a name, not beginning with "__"? Something like
MX1_DMA_REG, perhaps? Or maybe even we shall remap those registers?

Thanks
Guennadi

> /*
> * CSI registers
> */
> -#define DMA_CCR(x) (0x8c + ((x) << 6)) /* Control Registers */
> -#define DMA_DIMR 0x08 /* Interrupt mask Register */
> +#define DMA_CCR(x) __DMAREG(0x8c + ((x) << 6)) /* Control Registers */
> +#define DMA_DIMR __DMAREG(0x08) /* Interrupt mask Register */
> #define CSICR1 0x00 /* CSI Control Register 1 */
> #define CSISR 0x08 /* CSI Status Register */
> #define CSIRXR 0x10 /* CSI RxFIFO Register */
> @@ -783,7 +785,7 @@ static int __init mx1_camera_probe(struct platform_device *pdev)
> pcdev);
>
> imx_dma_config_channel(pcdev->dma_chan, IMX_DMA_TYPE_FIFO,
> - IMX_DMA_MEMSIZE_32, DMA_REQ_CSI_R, 0);
> + IMX_DMA_MEMSIZE_32, MX1_DMA_REQ_CSI_R, 0);
> /* burst length : 16 words = 64 bytes */
> imx_dma_config_burstlen(pcdev->dma_chan, 0);
>
> @@ -797,8 +799,8 @@ static int __init mx1_camera_probe(struct platform_device *pdev)
> set_fiq_handler(&mx1_camera_sof_fiq_start, &mx1_camera_sof_fiq_end -
> &mx1_camera_sof_fiq_start);
>
> - regs.ARM_r8 = DMA_BASE + DMA_DIMR;
> - regs.ARM_r9 = DMA_BASE + DMA_CCR(pcdev->dma_chan);
> + regs.ARM_r8 = (long)DMA_DIMR;
> + regs.ARM_r9 = (long)DMA_CCR(pcdev->dma_chan);
> regs.ARM_r10 = (long)pcdev->base + CSICR1;
> regs.ARM_fp = (long)pcdev->base + CSISR;
> regs.ARM_sp = 1 << pcdev->dma_chan;
> --
> 1.7.0
>

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: cpuset: alloc nodemask_t at heap not stack - fix
http://groups.google.com/group/linux.kernel/t/81da15ed0a3dc653?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Mar 12 2010 1:50 am
From: David Rientjes

On Fri, 12 Mar 2010, Miao Xie wrote:

> fix memory leak
>
> Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>
> ---
> Against the following patch in mmotm-2010-03-11-13-13:
> cpuset-alloc-nodemask_t-at-heap-not-stack.patch
> ---
> kernel/cpuset.c | 10 +++++++---
> 1 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/cpuset.c b/kernel/cpuset.c
> index f36e577..8e27d00 100644
> --- a/kernel/cpuset.c
> +++ b/kernel/cpuset.c
> @@ -1401,7 +1401,7 @@ static void cpuset_attach(struct cgroup_subsys *ss, struct cgroup *cont,
> NODEMASK_ALLOC(nodemask_t, to, GFP_KERNEL);
>
> if (from == NULL || to == NULL)
> - return;
> + goto alloc_fail;
>
> if (cs == &top_cpuset) {
> cpumask_copy(cpus_attach, cpu_possible_mask);
> @@ -1432,8 +1432,12 @@ static void cpuset_attach(struct cgroup_subsys *ss, struct cgroup *cont,
> mmput(mm);
> }
>
> - NODEMASK_FREE(from);
> - NODEMASK_FREE(to);
> +alloc_fail:
> + if (from)
> + NODEMASK_FREE(from);
> +
> + if (to)
> + NODEMASK_FREE(to);

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

==============================================================================
TOPIC: cpuset: fix the problem that cpuset_mem_spread_node() returns an
offline node - fix
http://groups.google.com/group/linux.kernel/t/54b73e7c0a319b73?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Mar 12 2010 1:50 am
From: David Rientjes

On Fri, 12 Mar 2010, Miao Xie wrote:

> Remove unnecessary smp_wmb().
>
> Signed-off-by: Miao Xie <miaox@cn.fujitsu.com>

Acked-by: David Rientjes <rientjes@google.com>

Andrew can easily fold this into its parent patch now before pushing to
Linus, thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: x86: irq_desc->chip_data is always correct whether or not SPARSE_IRQ is
enabled.
http://groups.google.com/group/linux.kernel/t/8d79051b75e0b2aa?hl=en
==============================================================================

== 1 of 2 ==
Date: Fri, Mar 12 2010 1:50 am
From: Ian Campbell

arch_early_irq_init ensures that in the non-SPARSE_IRQ case that
chip_data is only set for irq < NR_IRQS which means that the
SPARSE_IRQ version of irq_cfg behaves exactly the same as the
non-SPARSE_IRQ version when SPARSE_IRQ is disabled.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: x86@kernel.org
Cc: linux-kernel@vger.kernel.org
---
arch/x86/kernel/apic/io_apic.c | 9 ++-------
1 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 12e5cf4..afe81d6 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -178,7 +178,6 @@ int __init arch_early_irq_init(void)
return 0;
}

-#ifdef CONFIG_SPARSE_IRQ
struct irq_cfg *irq_cfg(unsigned int irq)
{
struct irq_cfg *cfg = NULL;
@@ -191,6 +190,8 @@ struct irq_cfg *irq_cfg(unsigned int irq)
return cfg;
}

+#ifdef CONFIG_SPARSE_IRQ
+
static struct irq_cfg *get_one_free_irq_cfg(int node)
{
struct irq_cfg *cfg;
@@ -331,16 +332,10 @@ void x86_free_chip_data(struct irq_desc *old_desc, struct irq_desc *desc)
/* end for move_irq_desc */

#else
-struct irq_cfg *irq_cfg(unsigned int irq)
-{
- return irq < nr_irqs ? irq_cfgx + irq : NULL;
-}
-
int x86_init_chip_data(struct irq_desc *desc, int node)
{
return 0;
}
-

twitter

Friday, March 12, 2010

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

0 Comments:

Post a Comment

About Me

Previous Posts