twitter: linux.kernel - 25 new messages in 23 topics

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

Today's topics:

==============================================================================
TOPIC: NOHZ vs. profile/oprofile v2
http://groups.google.com/group/linux.kernel/t/79bb21849045ad73?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Mar 2 2010 7:30 am
From: Martin Schwidefsky

On Tue, 2 Mar 2010 16:08:09 +0100 (CET)
Thomas Gleixner <tglx@linutronix.de> wrote:

> On Tue, 2 Mar 2010, Martin Schwidefsky wrote:
>
> > On Tue, 02 Mar 2010 15:57:22 +0200
> > Aaro Koskinen <aaro.koskinen@nokia.com> wrote:
> >
> > > Hi,
> > >
> > > Martin Schwidefsky wrote:
> > > > First version of the hrtimer patch for oprofile. I did not add the
> > > > sysctl yet, if the sysctl is added in oprofile_timer_init it would not
> > > > be available if some better profiling source is available. If it is
> > > > added unconditionally it would only have an effect if the timer
> > > > fallback is used. Both cases are not exactly nice for a user space
> > > > interface.
> > >
> > > I wonder what happened to this patch? Some platforms would need
> > > this fix (i.e. the timer mode has to be used due to HW issues).
> >
> > After SH removed their oprofile hook there is nothing left that would
> > prevent us from converting oprofile to hrtimer. Just a matter of
> > reminding me and have me try again ;-)
> >
> > Patch against current git. Ingo, Thomas: one for the timer tree I guess.
>
> No objections from my side, but shouldn't that go via Robert ?

Agreed, this should be handled by the oprofile maintainer.
Robert, could you take care of the patch?

--
blue skies,
Martin.

"Reality continues to ruin my life." - Calvin.

--
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: Tues, Mar 2 2010 7:40 am
From: Robert Richter

On 02.03.10 16:08:09, Thomas Gleixner wrote:
> > Patch against current git. Ingo, Thomas: one for the timer tree I guess.
>
> No objections from my side, but shouldn't that go via Robert ?

I will send the patch upstream.

-Robert

--
Advanced Micro Devices, Inc.
Operating System Research Center
email: robert.richter@amd.com

==============================================================================
TOPIC: Add sysfs support for fbdefio delay
http://groups.google.com/group/linux.kernel/t/fa05f291e1c0c50c?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 7:40 am
From: "Rick L. Vinyard, Jr."

Jaya Kumar wrote:
> On Tue, Mar 2, 2010 at 12:10 AM, Rick L. Vinyard, Jr.
> <rvinyard@cs.nmsu.edu> wrote:
>> Jaya Kumar wrote:
>>> Hi Rick,
>>>
>>> On Fri, Feb 26, 2010 at 6:15 AM, Rick L. Vinyard Jr.
>>> <rvinyard@cs.nmsu.edu> wrote:
>>>
>>>> + Set the deferred I/O delay of the framebuffer in ms.
>>>> + This value can be used to throttle deferred I/O
>>>> updates.
>>>
>>> Please help us understand how userspace should use the ability to set
>>> this delay.
>>
>> I think that there isn't one specific answer since, just like the
>> approach
>> to priority of processes there isn't one specific answer. The real
>> answer
>> is: it depends.
>
> Rick,
>
> Thanks for your reply.
>
>>
>> One of the factors I was concerned about was having two or more G13
>> devices on the same bus with other traffic. Each frame is sent as an
>> interrupt transfer out, and I was concerned that the framebuffer updates
>> might be detrimental to other traffic.
>>
>> I know that a pair of G13 devices running at 30 FPS would only consume
>> about 5% of the USB 1.1 bandwidth (~500 Mbit/s) for framebuffer
>> transfers
>> (sans headers and other control messages), but I was concerned that it
>> could introduce enough latency to make other devices laggy.
>
> You mentioned in your responses and above that you're concerned about
> saturating the USB bus and lagginess, and I think it is good to have
> those concerns. Defio delay may be an easy parameter to expose, and in
> at least a specific set of drivers, changing it would have a
> meaningful effect on bus utilization, but are you convinced that
> exposing it generally (remember your patch makes it apply to all fb
> drivers) to userspace is a right way or even a good way to address bus
> saturation concerns?
>
>> As a result of this translation, I was concerned with the driver
>> consuming
>> too much CPU time when doing multiple translations for multiple
>> devices...
>> or even one translation on a limited or saturated CPU at a high frame
>> rate.
>
> Being concerned about CPU utilization is a good thing. But say for
> example, your USB ethernet driver or USB audio driver is taking a lot
> of cpu time packetizing traffic, then would I be correct that your
> desire is to expose an inter-packetization driver specific sleep time
> controllable by userspace via sysfs for all ethernet, audio, etc
> drivers? (by driver specific, I mean the sysfs parameter would be
> presented by all drivers but the value would be specific to each one,
> which is the way your current patch would behave for all fb drivers).
>

I think the answer is yes, whether this were a fb, network, audio, etc. If
there is a clearly defined parameter at which resource utilization can be
adjusted in a standard way.

Although the value is specific to each one, the min/max parameters provide
the bounds and standardized units, allowing userspace to modify the delay
parameter in a standardized way.

I also tried to make it where the driver had to explicitly modify the
min/max parameters so that unless a driver sets min/max values the delay
parameter can be examined from userspace but not modified.

I agree that the motivation for throttling varies by device, and even as
in this case there could be different motivations for the same device (USB
bus bandwidth and/or CPU utilization).

I think that what also distinguishes the fbdefio case is the fact that
there is a single defined point at which resource utilization would be
throttled and that's the fb_deferred_io structure's deferred_io hook.

>> I think it would be an interesting possibility to develop a daemon that
>> watched traffic on buses with USB devices that could be throttled and
>> throttle them according to bus saturation.
>>
>> However, at this point I wasn't planning on going there. But, having the
>> ability to throttle would be a key point for developing such daemons.
>
> Just curious, do such sysfs throttling parameters exist for any other
> subsystems? If so, are userspace apps/services using them, and are
> they happy with it?

An example of something like this is the ACPI CPU thermal class. It
provides two parameters, cur_state and max_state. The minimum is presumed
to be 0.

In this case though, I think fbdefio needs to provide both a min and a max
as a driver may want to set the minimum refresh rate to be non-zero.

Another example would be the CPU frequency subsystem, and in particular
the userspace governor. There are similar sysfs attributes for obtaining
the current frequency, setting the frequency, and obtaining the min/max
frequencies.

In particular they used:
scaling_cur_freq (ro)
scaling_min_freq (ro)
scaling_max_freq (ro)
scaling_setspeed (wo)

I used a single read/write attribute for read/write on the delay instead
of the two parameter approach used for frequencies. I used:
defio_delay (rw)
defio_delay_min (ro)
defio_delay_max (ro)

But, it wouldn't be hard to use an analogous set like:
defio_cur_delay (ro)
defio_min_delay (ro)
defio_max_delay (ro)
defio_set_delay (wo)

Rick

==============================================================================
TOPIC: Notifier chains bug ?
http://groups.google.com/group/linux.kernel/t/a606a720e08102c8?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 7:50 am
From: Américo Wang

On Tue, Mar 02, 2010 at 07:50:01AM +0200, Oleg Kutkov wrote:
>2010/3/2 Américo Wang <xiyou.wangcong@gmail.com>:
>> On Tue, Mar 2, 2010 at 8:08 AM, Oleg Kutkov <elenbert@gmail.com> wrote:
>>> Hello.
>>> I try to used notifier chains for monitoring network devices events.
>>> All works perfectly when just i'm connecting/disconnecting network cable or
>>> up/down interface via ifconfig.
>>> But when i try to change interface address - nothing happens. Notifier is
>>> don't send any events :(
>>
>> I think you mean IP address? No, NETDEV_CHANGEADDR is for hardware
>> address, not for IP address.
>>
>> If you were changing mac address, you will receive NETDEV_CHANGEADDR.
>>
>
>Thank for quick answer.
>Yes, i mean IP address. And what about NETDEV_CHANGE ?

It is for rtnetlink state transition.

>Is there possible for monitoring IP address/netmask changing ?
>

AFAIK, no.

Cc'ing netdev experts...
--
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: unable to handle kernel paging request on resume with 2.6.33-00001-
gbaac35c
http://groups.google.com/group/linux.kernel/t/f6bf94c5aedebc4a?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 7:50 am
From: Michal Hocko

On Tue, Mar 02, 2010 at 09:25:43AM +0100, Michal Hocko wrote:
> On Tue, Mar 02, 2010 at 01:06:06AM +0100, Rafael J. Wysocki wrote:
> > On Monday 01 March 2010, Michal Hocko wrote:
> > > [Let's CC mm guys]
> >
> > I guess it's rather architecture-related than a genering mm issue.
> >
> > > On Mon, Mar 01, 2010 at 10:07:37PM +0100, Rafael J. Wysocki wrote:
> > > > On Monday 01 March 2010, Michal Hocko wrote:
> > > > > Hi,
> > > > >
> > > > > I have experienced the following kernel BUG on resume from suspend from
> > > > > disk (the whole log from hibarnation to suspend along with kernel
> > > > > config are attached):
> > > > >
> > > > > BUG: unable to handle kernel paging request at 00aaaaaa
> > > > > IP: [<c019e28c>] anon_vma_link+0x2c/0x39
> > > > > *pde = 00000000
> > > > > Oops: 0002 [#1] PREEMPT SMP
> > > > > last sysfs file: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/AC/type
> > > > > Modules linked in: aes_i586 aes_generic iwl3945 iwlcore mac80211 cfg80211 fbcon font bitblit softcursor i915 drm_kms_helper drm fb i2c_algo_bit cfbcopyarea i2c_core cfbimgblt cfbfillrect fuse tun coretemp hwmon snd_hda_codec_realtek snd_hda_intel snd_hda_codec arc4 ecb snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_oss snd_seq_midi_event snd_seq snd_timer fujitsu_laptop snd_seq_device rtc_cmos rtc_core led_class rtc_lib snd snd_page_alloc video backlight output [last unloaded: cfg80211]
> > > > >
> > > > > Pid: 3942, comm: kxkb Not tainted 2.6.33-00001-gbaac35c #11 FJNB1B5/LIFEBOOK S7110
> > > > > EIP: 0060:[<c019e28c>] EFLAGS: 00010246 CPU: 1
> > > > > EIP is at anon_vma_link+0x2c/0x39
> > > > > EAX: 00aaaaaa EBX: f69c6410 ECX: f69c6414 EDX: f63e4df4
> > > > > ESI: f63e4dc0 EDI: f63e4e14 EBP: f6901ec0 ESP: f6901eb8
> > > > > DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
> > > > > Process kxkb (pid: 3942, ti=f6901000 task=f6aa6ff0 task.ti=f6901000)
> > > > > Stack:
> > > > > f63e4dc0 f23fc7e4 f6901efc c012fc28 f6aa6ff0 f63e4e30 f63e4e34 f63e4e24
> > > > > <0> ca4656f4 f6ace734 f6aa6ff0 f6ace700 ca4656c0 f23fc790 ca560000 fffffff4
> > > > > <0> f659ef94 f6901f38 c0130821 f6aa6ff0 f6901fb4 bff441f0 ca560208 00000000
> > > > > Call Trace:
> > > > > [<c012fc28>] ? dup_mm+0x1c7/0x3d3
> > > > > [<c0130821>] ? copy_process+0x98e/0xf26
> > > > > [<c0130ed6>] ? do_fork+0x11d/0x2a1
> > > > > [<c0434547>] ? _raw_spin_unlock+0x14/0x28
> > > > > [<c01b6795>] ? set_close_on_exec+0x45/0x4b
> > > > > [<c01b6e98>] ? do_fcntl+0x15f/0x3f1
> > > > > [<c0108678>] ? sys_clone+0x20/0x25
> > > > > [<c010291d>] ? ptregs_clone+0x15/0x38
> > > > > [<c0102850>] ? sysenter_do_call+0x12/0x26
> > > > > Code: 89 e5 56 53 0f 1f 44 00 00 8b 58 3c 89 c6 85 db 74 22 89 d8 e8 54 65 29 00 8b 43 08 8d 56 34 8d 4b 04 89 53 08 89 4e 34 89 46 38 <89> 10 89 d8 e8 9e 62 29 00 5b 5e 5d c3 55 89 e5 0f 1f 44 00 00
> > > > > EIP: [<c019e28c>] anon_vma_link+0x2c/0x39 SS:ESP 0068:f6901eb8
> > > > > CR2: 0000000000aaaaaa
> > > > > ---[ end trace b7f008b0e5aa7c65 ]---
> > > >
> > > > This looks like a low-level memory management issue of some sort.
> > >
> > > Yes, it really looks strange. dup_mm+0x1c7 matches to:
> > > c102fc0e: 81 60 14 ff df ff ff andl $0xffffdfff,0x14(%eax)
> > > c102fc15: 8b 45 ec mov -0x14(%ebp),%eax
> > > c102fc18: c7 43 0c 00 00 00 00 movl $0x0,0xc(%ebx)
> > > c102fc1f: 89 03 mov %eax,(%ebx)
> > > c102fc21: 89 d8 mov %ebx,%eax
> > > c102fc23: e8 38 e6 06 00 call c109e260 <anon_vma_link>
> > > c102fc28: 8b 43 48 mov 0x48(%ebx),%eax <<< BANG
> > >
> > > which corresponds to:
> > > kernel/fork.c:336
> > > tmp->vm_flags &= ~VM_LOCKED;
> > > tmp->vm_mm = mm;
> > > tmp->vm_next = NULL;
> > > anon_vma_link(tmp);
> > > file = tmp->vm_file; <<< BANG
> > >
> > > ebx is tmp which somehow got deallocated. I cannot see how this could happened.
> >
> > Through a page tables corruption or a TLB issue, for example.
>
> I thought so. Is there any other possibility? Like a race with vma
> unlinking?

It really looks like some memory corruption. Now I got the following:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<c026db57>] strcmp+0xe/0x22
*pde = 00000000
Oops: 0000 [#1] PREEMPT SMP
last sysfs file: /sys/devices/pci0000:00/0000:00:1e.0/0000:08:03.4/fw-host0/00000e1003d248c6/uevent
Modules linked in: fbcon font bitblit softcursor i915 drm_kms_helper drm fb i2c_algo_bit cfbcopyarea i2c
on snd_hda_codec_realtek arc4 ecb snd_hda_intel snd_hda_codec snd_pcm_oss snd_mixer_oss snd_pcm iwl3945
d_timer snd_seq_device mac80211 snd fujitsu_laptop rtc_cmos cfg80211 rtc_core rtc_lib led_class snd_page
i_wait_scan]

Pid: 16719, comm: udev-acl.ck Not tainted 2.6.33-00001-gbaac35c #11 FJNB1B5/LIFEBOOK S7110
EIP: 0060:[<c026db57>] EFLAGS: 00010286 CPU: 0
EIP is at strcmp+0xe/0x22
EAX: 00000000 EBX: f71c0600 ECX: f70d0f00 EDX: f5a1d49c
ESI: 00000000 EDI: f5a1d49c EBP: f70d0dec ESP: f70d0de4
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process udev-acl.ck (pid: 16719, ti=f70d0000 task=f6a65710 task.ti=f70d0000)
Stack:
f5a1d49c fffffffe f70d0dfc c01ea0c0 f5a1d440 f71c05a0 f70d0e14 c01ea267
<0> f5a1d330 c044cfac f70d0f00 f6f44968 f70d0e3c c01b3a14 f70fcc80 f70d0e7c
<0> f6f449e0 f5a1d330 f5a1d440 f70d0f00 f6f44968 087bed70 f70d0e90 c01b508a
Call Trace:
[<c01ea0c0>] ? sysfs_find_dirent+0x1b/0x2c
[<c01ea267>] ? sysfs_lookup+0x2f/0xa6
[<c01b3a14>] ? do_lookup+0xca/0x174
[<c01b508a>] ? link_path_walk+0x691/0xa22
[<c01bf3e8>] ? mntput_no_expire+0x1e/0xb2
[<c01b552c>] ? path_walk+0x3f/0x89
[<c01b3dd1>] ? path_init+0x73/0x114
[<c01b5601>] ? do_path_lookup+0x26/0x47
[<c01b6072>] ? do_filp_open+0xdc/0x79e
[<c01899d0>] ? free_hot_page+0x55/0x59
[<c01eaad0>] ? sysfs_put_link+0x0/0x1f
[<c0189a6b>] ? free_pages+0x22/0x24
[<c01b3d54>] ? generic_readlink+0x69/0x73
[<c04371c9>] ? add_preempt_count+0x8/0x75
[<c0437155>] ? sub_preempt_count+0x8/0x74
[<c0434547>] ? _raw_spin_unlock+0x14/0x28
[<c01aae0a>] ? do_sys_open+0x4d/0xe9
[<c01aad0e>] ? filp_close+0x56/0x60
[<c01aaef2>] ? sys_open+0x23/0x2b
[<c0102850>] ? sysenter_do_call+0x12/0x26
Code: 31 c0 83 c9 ff f2 ae 4f 89 d1 49 78 06 ac aa 84 c0 75 f7 31 c0 aa 89 d8 5b 5e 5f 5d c3 55 89 e5 57 56 0f 1f 44 00 00 89 c6 89 d7 <ac> ae 75 08 84 c0 75 f8 31 c0 eb 04 19 c0 0c 01 5e 5f 5d c3 55
EIP: [<c026db57>] strcmp+0xe/0x22 SS:ESP 0068:f70d0de4
CR2: 0000000000000000
---[ end trace 877af85bb64785ae ]---

>
> >
> > > > What's the HEAD commit in this kernel tree?
> > >
> > > $ git describe
> > > v2.6.33-1-gbaac35c
> >
> > I can't find gbaac35c anywhere post 2.6.33.
>
> you should look at baac35c. Git describe displays gHASH
>
> > Can you just send the output
> > of "git show | head -1", please?
>
> The whole commit ID is baac35c4155a8aa826c70acee6553368ca5243a2
>
> >
> > > > Also, is the problem reproducible?
> > >
> > > As I've already mentioned. This is the first time I have seen this problem.
> > > I am using suspend to disk and wake up quite often (several times a day). I
> > > haven't tried suspend/resume loop test yet.
> >
> > OK
> >
> > Given the apparent nature of the problem it will be extremely difficult to
> > track down without a reliable way to reproduce it.
>
> Yes, I am aware of that but maybe someone will face the same problem.
> Let's see whether I am able to reproduce.
>
> >
> > Rafael
>
> --
> Michal Hocko

--
Michal Hocko
--
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: memcg: dirty pages instrumentation
http://groups.google.com/group/linux.kernel/t/98b8f3d66410be44?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 8:00 am
From: Trond Myklebust

On Tue, 2010-03-02 at 14:48 +0100, Peter Zijlstra wrote:
> unsigned long reclaimable_pages(cgroup)
> {
> if (mem_cgroup_has_dirty_limit(cgroup))
> return mem_cgroup_page_stat(MEMCG_NR_RECLAIM_PAGES);
>
> return global_page_state(NR_FILE_DIRTY) + global_page_state(NR_NFS_UNSTABLE);
> }
>
> Which raises another question, you should probably rebase on top of
> Trond's patches, which removes BDI_RECLAIMABLE, suggesting you also
> loose MEMCG_NR_RECLAIM_PAGES in favour of the DIRTY+UNSTABLE split.
>

I'm dropping those patches for now. The main writeback change wasn't too
favourably received by the linux-mm community so I've implemented an
alternative that only changes the NFS layer, and doesn't depend on the
DIRTY+UNSTABLE split.

Cheers
Trond

==============================================================================
TOPIC: kbuild - tags
http://groups.google.com/group/linux.kernel/t/02f781aad175f6a4?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 8:00 am
From: John Kacur

- Add the ability to make tags for all archs using "all"
make ALLSOURCE_ARCHS=all tags
- Document this in kbuild.txt

Without this change you have to type each arch separately.

Signed-off-by: John Kacur <jkacur@redhat.com>
---
Documentation/kbuild/kbuild.txt | 4 ++++
scripts/tags.sh | 11 +++++++++++
2 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/Documentation/kbuild/kbuild.txt b/Documentation/kbuild/kbuild.txt
index 6f8c1ca..a6791e3 100644
--- a/Documentation/kbuild/kbuild.txt
+++ b/Documentation/kbuild/kbuild.txt
@@ -162,3 +162,7 @@ For tags/TAGS/cscope targets, you can specify more than one arch
to be included in the databases, separated by blank space. E.g.:

$ make ALLSOURCE_ARCHS="x86 mips arm" tags
+
+To get all available archs you can also specify all. E.g.:
+
+ $ make ALLSOURCE_ARCHS=all tags
diff --git a/scripts/tags.sh b/scripts/tags.sh
index a6a8e71..766eb8a 100755
--- a/scripts/tags.sh
+++ b/scripts/tags.sh
@@ -24,9 +24,20 @@ else
tree=${srctree}/
fi

+# Find all available archs
+find_all_archs()
+{
+ ALLSOURCE_ARCHS=""
+ for arch in `ls ${tree}arch`; do
+ ALLSOURCE_ARCHS="${ALLSOURCE_ARCHS} "${arch##\/}
+ done
+}
+
# Detect if ALLSOURCE_ARCHS is set. If not, we assume SRCARCH
if [ "${ALLSOURCE_ARCHS}" = "" ]; then
ALLSOURCE_ARCHS=${SRCARCH}
+elif [ "${ALLSOURCE_ARCHS}" = "all" ]; then
+ find_all_archs
fi

# find sources in arch/$ARCH
--
1.6.6.1

==============================================================================
TOPIC: drivers: net: optimize hex2bin()
http://groups.google.com/group/linux.kernel/t/766d35ce753992f1?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 8:10 am
From: Geoff Levand

On 03/01/2010 11:59 PM, Andy Shevchenko wrote:
> Optimize hex2bin() function used in ps3_gelic_wireless.c. It requires to have
> hex_to_bin() implementation introduced by starter patch [1] in series.
>
> [1] http://patchwork.kernel.org/patch/81224/
>
> Signed-off-by: Andy Shevchenko <ext-andriy.shevchenko@nokia.com>
> Cc: Geoff Levand <geoffrey.levand@am.sony.com>
> ---
> drivers/net/ps3_gelic_wireless.c | 13 +++++--------
> 1 files changed, 5 insertions(+), 8 deletions(-)

Looks good, thanks.

Acked-by: Geoff Levand <geoffrey.levand@am.sony.com>

==============================================================================
TOPIC: OMAP DSS updates for 2.6.34
http://groups.google.com/group/linux.kernel/t/87f178be5609e4b9?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 8:10 am
From: Tomi Valkeinen

Hi Linus,

Please pull the OMAP Display Subsystem patches below.

- Couple of new panel drivers
- Various small fixes and improvements
- Multiple patches making the DSS device model more sane, moving the
control from the DSS core driver to the panel drivers. This makes it
possible for the panel drivers to fully control what is going on,
instead of having to work with the limits imposed by the DSS core.

Tomi

The following changes since commit 13dda80e48439b446d0bc9bab34b91484bc8f533:
Linus Torvalds (1):
Merge branch 'davinci-for-linus' of git://git.kernel.org/.../khilman/linux-davinci

are available in the git repository at:

git://gitorious.org/linux-omap-dss2/linux.git for-linus

Aaro Koskinen (1):
OMAP: DSS: Taal: fix error returns in taal_probe()

Grazvydas Ignotas (1):
OMAP: DSS: add TPO TD043MTEA1 panel

Janusz Krzysztofik (2):
omapfb: Fix 12-bit display (RGB444 color mode) handling
omapfb: lcd_ams_delta: add support for contrast control

Mike Rapoport (1):
OMAP: DSS2: add Toppoly TDO35S panel

Tomi Valkeinen (41):
OMAP: DSS2: Improve Kconfig help texts
OMAP: DSS2: enable VDDS_DSI when using DPI
OMAP: 3430SDP: remove vdvi regulator
OMAP: DSS2: OMAPFB: implement OMAPFB_GET_DISPLAY_INFO
OMAP: DSS2: fix irq-stats compilation
OMAP: DSS2: OMAPFB: Add omapfb_update_window prototype
OMAP: DSS2: improve DSS clk src selection
OMAP: DSS2: DSI: add dsi_bus_is_locked()
OMAP: DSS2: DSI: add helpers for DCS read/write
OMAP: DSS2: DSI: export dsi_vc_enable_hs()
OMAP: DSS2: DSI: configure all DSI VCs
OMAP: DSS2: DSI: remove dsi_vc_print_status()
OMAP: DSS2: Check ctx loss count only when starting the first clock
OMAP: DSS2: remove sub-panel system
OMAP: DSS2: fix driver probe error handling
OMAP: DSS2: OMAPFB: fix dssdev cleanup on error
OMAP: DSS2: OMAPFB: fix cleanup on dssdev enable error
OMAP: DSS2: fix get_dsi/dispc_clk_source() usage
OMAP: DSS2: DSI: change DSI bus_lock to semaphore
OMAP: DSS2: DSI: remove auto-update perf measurement
OMAP: DSS2: move run_test()
OMAP: DSS2: move memory_read()
OMAP: DSS2: move set/get_mirror()
OMAP: DSS2: move get/set_rotate()
OMAP: DSS2: move wait_vsync()
OMAP: DSS2: move enable/disable_channel to overlay manager
OMAP: DSS2: move get_resolution()
OMAP: DSS2: move get_recommended_bpp()
OMAP: DSS2: move enable/get_te()
OMAP: DSS2: move set/get_update_mode()
OMAP: DSS2: move update() and sync()
OMAP: DSS2: move enable/disable/suspend/resume
OMAP: DSS2: move set/get_wss()
OMAP: DSS2: move timing functions
OMAP: DSS2: DSI: remove external TE support
OMAP: DSS2: OMAPFB: Remove FB_OMAP2_FORCE_AUTO_UPDATE
OMAP: DSS2: DSI: add dsi_vc_dcs_read_2() helper
OMAP: DSS2: TPO-TD03MTEA1: fix function names
OMAP: DSS2: DSI: add error prints
OMAP: DSS2: Taal: Fix ESD check
OMAP: DSS2: Taal: Fix TE when resuming

Vaibhav Hiremath (1):
OMAP: DSS2: Add Sharp LQ043T1DG01 panel driver

Ville Syrjälä (2):
OMAP: DSS2: OMAPFB: install omapfb.h
OMAP: DSS2: OMAPFB: Constify some function parameters

arch/arm/mach-omap2/board-3430sdp.c | 4 -
arch/arm/plat-omap/include/plat/display.h | 117 ++-
drivers/video/omap/lcd_ams_delta.c | 93 ++-
drivers/video/omap/omapfb_main.c | 7 +-
drivers/video/omap2/displays/Kconfig | 18 +
drivers/video/omap2/displays/Makefile | 3 +
drivers/video/omap2/displays/panel-generic.c | 56 +-
.../video/omap2/displays/panel-sharp-lq043t1dg01.c | 159 +++
.../video/omap2/displays/panel-sharp-ls037v7dw01.c | 77 +-
drivers/video/omap2/displays/panel-taal.c | 253 ++++-
.../video/omap2/displays/panel-toppoly-tdo35s.c | 154 +++
.../video/omap2/displays/panel-tpo-td043mtea1.c | 528 ++++++++++
drivers/video/omap2/dss/Kconfig | 26 +-
drivers/video/omap2/dss/core.c | 117 ++-
drivers/video/omap2/dss/dispc.c | 42 +-
drivers/video/omap2/dss/display.c | 119 +--
drivers/video/omap2/dss/dpi.c | 144 +---
drivers/video/omap2/dss/dsi.c | 1031 +++++---------------
drivers/video/omap2/dss/dss.c | 42 +-
drivers/video/omap2/dss/dss.h | 23 +-
drivers/video/omap2/dss/manager.c | 48 +-
drivers/video/omap2/dss/overlay.c | 2 +-
drivers/video/omap2/dss/rfbi.c | 321 +------
drivers/video/omap2/dss/sdi.c | 115 +--
drivers/video/omap2/dss/venc.c | 296 +++----
drivers/video/omap2/omapfb/Kconfig | 11 +-
drivers/video/omap2/omapfb/omapfb-ioctl.c | 68 +-
drivers/video/omap2/omapfb/omapfb-main.c | 133 ++--
drivers/video/omap2/omapfb/omapfb.h | 9 +
include/linux/Kbuild | 1 +
include/linux/omapfb.h | 9 +
31 files changed, 2186 insertions(+), 1840 deletions(-)
create mode 100644 drivers/video/omap2/displays/panel-sharp-lq043t1dg01.c
create mode 100644 drivers/video/omap2/displays/panel-toppoly-tdo35s.c
create mode 100644 drivers/video/omap2/displays/panel-tpo-td043mtea1.c

==============================================================================
TOPIC: mfd/tc6393xb: don't use devinit data from non-init function
http://groups.google.com/group/linux.kernel/t/aed2b5f5b8026e97?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 8:30 am
From: Uwe Kleine-König

tc6393xb_mmc_resources (which was marked __devinitdata) is used in
tc6393xb_mmc_enable() and tc6393xb_mmc_resume() which both are functions
living in .text. This is not save with CONFIG_HOTPLUG=n.

This was introduced in

64e8867 (mfd: tmio_mmc hardware abstraction for CNF area)

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: Ian Molton <ian@mnementh.co.uk>
Cc: Magnus Damm <damm@opensource.se>
Cc: Samuel Ortiz <sameo@linux.intel.com>
---
drivers/mfd/tc6393xb.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/mfd/tc6393xb.c b/drivers/mfd/tc6393xb.c
index 4bc5a08..b057d8d 100644
--- a/drivers/mfd/tc6393xb.c
+++ b/drivers/mfd/tc6393xb.c
@@ -154,7 +154,7 @@ static struct resource __devinitdata tc6393xb_nand_resources[] = {
},
};

-static struct resource __devinitdata tc6393xb_mmc_resources[] = {
+static struct resource tc6393xb_mmc_resources[] = {
{
.start = 0x800,
.end = 0x9ff,
--
1.7.0

==============================================================================
TOPIC: x86, mm: NX protection for kernel data
http://groups.google.com/group/linux.kernel/t/f443973b61e7d544?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 8:30 am
From: castet.matthieu@free.fr

> At this point I need some help and guidance on how to track down what
> exactly happens there, as I am not very familiar with what goes into
> .data and why are we trying to execute it.
Can't you add debug printk in the fault handler before any exception processing

Something like that.

Matthieu

==============================================================================
TOPIC: sched: Fix group_capacity for sched_smt_powersavings=1
http://groups.google.com/group/linux.kernel/t/c1850d2e9e828197?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 8:30 am
From: Vaidyanathan Srinivasan

Hi Peter,

After applying Suresh's fixes from discussion thread
http://lkml.org/lkml/2010/2/12/352, we still need the attached patch
to restore sched_smt_powersavings=1 functionality where tasks prefer
sibling threads and keep more cores idle.

I am reposting the patch from http://lkml.org/lkml/2010/2/16/291

Please apply to sched-tip, the patch is based on today's sched-tip
master.

The attached patch will run 4 while(1) loops in two cores when
sched_smt_power_savings=1. Tested on two socket, quad core, hyper
threaded system.

Thanks,
Vaidy
---
sched: Fix group_capacity for sched_smt_powersavings=1

sched_smt_powersavings for threaded systems need this fix for
consolidation to sibling threads to work. Since threads have
fractional capacity, group_capacity will turn out to be one
always and not accommodate another task in the sibling thread.

This fix makes group_capacity a function of cpumask_weight that
will enable the power saving load balancer to pack tasks among
sibling threads and keep more cores idle.

Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>

diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
index 5a5ea2c..7c0a29a 100644
--- a/kernel/sched_fair.c
+++ b/kernel/sched_fair.c
@@ -2538,6 +2538,21 @@ static inline void update_sd_lb_stats(struct sched_domain *sd, int this_cpu,
*/
if (prefer_sibling)
sgs.group_capacity = min(sgs.group_capacity, 1UL);
+ /*
+ * If power savings balance is set at this domain, then
+ * make capacity equal to number of hardware threads to
+ * accommodate more tasks until capacity is reached.
+ */
+ else if (sd->flags & SD_POWERSAVINGS_BALANCE)
+ sgs.group_capacity =
+ cpumask_weight(sched_group_cpus(group));
+
+ /*
+ * The default group_capacity is rounded from sum of
+ * fractional cpu_powers of sibling hardware threads
+ * in order to enable fair use of available hardware
+ * resources.
+ */

if (local_group) {
sds->this_load = sgs.avg_load;
@@ -2863,7 +2878,8 @@ static int need_active_balance(struct sched_domain *sd, int sd_idle, int idle)
!test_sd_parent(sd, SD_POWERSAVINGS_BALANCE))
return 0;

- if (sched_mc_power_savings < POWERSAVINGS_BALANCE_WAKEUP)
+ if (sched_mc_power_savings < POWERSAVINGS_BALANCE_WAKEUP &&
+ sched_smt_power_savings < POWERSAVINGS_BALANCE_WAKEUP)
return 0;
}

--
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: perf_events, x86: Fixup fixed counter constraints
http://groups.google.com/group/linux.kernel/t/ccab234928070dfe?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 8:30 am
From: Stephane Eranian

On Tue, Mar 2, 2010 at 3:31 PM, tip-bot for Peter Zijlstra
<a.p.zijlstra@chello.nl> wrote:
>
> Commit-ID: b622d644c7d61a5cb95b74e7b143c263bed21f0a
> Gitweb: http://git.kernel.org/tip/b622d644c7d61a5cb95b74e7b143c263bed21f0a
> Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
> AuthorDate: Mon, 1 Feb 2010 15:36:30 +0100
> Committer: Ingo Molnar <mingo@elte.hu>
> CommitDate: Tue, 2 Mar 2010 15:06:47 +0100
>
> perf_events, x86: Fixup fixed counter constraints
>
> Patch 1da53e0230 ("perf_events, x86: Improve x86 event scheduling")
> lost us one of the fixed purpose counters and then ed8777fc13
> ("perf_events, x86: Fix event constraint masks") broke it even
> further.
>
> Widen the fixed event mask to event+umask and specify the full config
> for each of the 3 fixed purpose counters. Then let the init code fill
> out the placement for the GP regs based on the cpuid info.
>
> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Cc: Stephane Eranian <eranian@google.com>
> LKML-Reference: <new-submission>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>

> static struct event_constraint intel_core2_event_constraints[] =
> {
> - FIXED_EVENT_CONSTRAINT(0xc0, (0x3|(1ULL<<32))), /* INSTRUCTIONS_RETIRED */
> - FIXED_EVENT_CONSTRAINT(0x3c, (0x3|(1ULL<<33))), /* UNHALTED_CORE_CYCLES */
> + FIXED_EVENT_CONSTRAINT(0x00c0, 0), /* INST_RETIRED.ANY */
> + FIXED_EVENT_CONSTRAINT(0x003c, 1), /* CPU_CLK_UNHALTED.CORE */
> + /*
> + * Core2 has Fixed Counter 2 listed as CPU_CLK_UNHALTED.REF and event
> + * 0x013c as CPU_CLK_UNHALTED.BUS and specifies there is a fixed
> + * ratio between these counters.
> + */
> + /* FIXED_EVENT_CONSTRAINT(0x013c, 2), CPU_CLK_UNHALTED.REF */
> INTEL_EVENT_CONSTRAINT(0x10, 0x1), /* FP_COMP_OPS_EXE */
> INTEL_EVENT_CONSTRAINT(0x11, 0x2), /* FP_ASSIST */
> INTEL_EVENT_CONSTRAINT(0x12, 0x2), /* MUL */
> @@ -37,14 +43,16 @@ static struct event_constraint intel_core2_event_constraints[] =
> INTEL_EVENT_CONSTRAINT(0x18, 0x1), /* IDLE_DURING_DIV */
> INTEL_EVENT_CONSTRAINT(0x19, 0x2), /* DELAYED_BYPASS */
> INTEL_EVENT_CONSTRAINT(0xa1, 0x1), /* RS_UOPS_DISPATCH_CYCLES */
> + INTEL_EVENT_CONSTRAINT(0xc9, 0x1), /* ITLB_MISS_RETIRED (T30-9) */

Where does the constraint on ITLB_MISS_RETIRED come from?
--
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: oprofile: updates for v2.6.34
http://groups.google.com/group/linux.kernel/t/be4a0d6ab576b080?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 8:50 am
From: Robert Richter

Ingo,

it's only one patch, please pull from:

git://git.kernel.org/pub/scm/linux/kernel/git/rric/oprofile.git urgent

(It seems the git mirror is not yet sync'ed.)

Thanks,

-Robert

The following changes since commit cfc9c0b450176a077205ef39092f0dc1a04e020a:
Robert Richter (1):
oprofile/x86: fix msr access to reserved counters

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/rric/oprofile.git ..BRANCH.NOT.VERIFIED..

Martin Schwidefsky (1):
oprofile: convert oprofile from timer_hook to hrtimer

drivers/oprofile/oprof.c | 12 ++++--
drivers/oprofile/oprof.h | 3 +-
drivers/oprofile/timer_int.c | 78 +++++++++++++++++++++++++++++++++++++-----
3 files changed, 79 insertions(+), 14 deletions(-)

==============================================================================
TOPIC: Booting kernel on 2nd Core
http://groups.google.com/group/linux.kernel/t/eb8d4aa9836b30ef?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 9:00 am
From: Swapnil Pimpale

Hi all,

I am working on Intel Core 2 Duo processor. As part of my academic
project, I want to boot Linux Kernel from 2nd core. I have
successfully jumped to the start address (1MB) of the kernel from 2nd
core. But it gets stuck in the function calibrate_delay().
If I comment the call to calibrate_delay and proceed with the kernel
boot-up, it goes ahead and gets stuck at some other point (in
acpi_ut_osi_implementation()).
In the meanwhile I have put the 1st core in an infinite loop.
I have configured the kernel to be an uni-processor kernel. (i.e.
disabled SMP support)

Could someone please let me know the reason for this problem. Will I
have to make any changes to kernel code for it to boot on 2nd core?

Thanks,
Swapnil A. Pimpale.
--
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: Oops while booting 2.6.34-rc0 (block pull busted)
http://groups.google.com/group/linux.kernel/t/f7420e106a3c28db?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 9:00 am
From: Michael Breuer

On 3/2/2010 5:13 AM, walt wrote:
> On 03/02/2010 12:15 AM, Jens Axboe wrote:
>>> On Mon, Mar 01 2010, Dmitry Torokhov wrote:
>
>>>> It looks like block tree that has been pulled today into mainline is
>>>> busted, I am getting the Opps below on boot with the following commit:
>>>>
>>>> commit b1bf9368407ae7e89d8a005bb40beb70a41df539
>
>
>> ....Can you also try and see if reverting
>> 9f7cdbc33f36d28e57eaba0093f68f0d14c38c5b makes it work?
>
> I'm getting the same oops and reverting that commit fixes it, thanks.
> I'm happy to test patches, etc.
>
Same here - was unable to boot - revert of this solved the issue.

==============================================================================
TOPIC: fuse updates for 2.6.34
http://groups.google.com/group/linux.kernel/t/20881bc153effd06?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 9:00 am
From: Miklos Szeredi

Hi Linus,

Please pull these fuse updates from:

git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git for-linus

Thanks,
Miklos
----

Fang Wenqi (1):
fuse: fix large stack use

Miklos Szeredi (1):
fuse: cleanup in fuse_notify_inval_...()

---
fs/fuse/dev.c | 30 +++++++++++++++---------------
1 files changed, 15 insertions(+), 15 deletions(-)
--
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: bridge: depends on INET
http://groups.google.com/group/linux.kernel/t/9c4fcb17427b7c42?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Mar 2 2010 9:10 am
From: Randy Dunlap

From: Randy Dunlap <randy.dunlap@oracle.com>

br_multicast calls ip_send_check(), so it should depend on INET.

built-in:
br_multicast.c:(.text+0x88cf4): undefined reference to `ip_send_check'

or modular:
ERROR: "ip_send_check" [net/bridge/bridge.ko] undefined!

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Stephen Hemminger <shemminger@linux-foundation.org>
Cc: bridge@lists.linux-foundation.org
---
net/bridge/Kconfig | 1 +
1 file changed, 1 insertion(+)

--- linux-next-20100302.orig/net/bridge/Kconfig
+++ linux-next-20100302/net/bridge/Kconfig
@@ -35,6 +35,7 @@ config BRIDGE
config BRIDGE_IGMP_SNOOPING
bool "IGMP snooping"
depends on BRIDGE
+ depends on INET
default y
---help---
If you say Y here, then the Ethernet bridge will be able selectively
--
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: Tues, Mar 2 2010 9:20 am
From: Randy Dunlap

On 03/01/10 23:09, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20100301:

linux-next-20100302/drivers/watchdog/wdt.c: In function 'wdt_ioctl':
linux-next-20100302/drivers/watchdog/wdt.c:370: error: assignment of read-only variable 'ident'
linux-next-20100302/drivers/watchdog/wdt.c:373: error: assignment of read-only variable 'ident'
linux-next-20100302/drivers/watchdog/wdt.c:375: error: assignment of read-only variable 'ident'
make[3]: *** [drivers/watchdog/wdt.o] Error 1

--
~Randy
--
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: USB mass storage and ARM cache coherency
http://groups.google.com/group/linux.kernel/t/68938cdf1fa061a9?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 9:10 am
From: Catalin Marinas

On Tue, 2010-03-02 at 21:11 +0900, FUJITA Tomonori wrote:
> On Sun, 28 Feb 2010 10:31:03 +0530
> James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> > But the point of all of this is that I cache invalidation doesn't appear
> > anywhere in the I/O path ... so if we're getting I/D incoherency,
> > there's some problem in the mm code (or there's a missing arch
> > assumption ... like I cache gets moved in more aggressively than we
> > expect). Parisc is very sensitive to I/D incoherency, so we'd notice if
> > there were a serious generic problem here.
>
> I'm not sure that there are some problems in the mm or common code. Is
> this ARM's implementation issue? (Of course, the usb stack and the
> driver's misuse of the DMA API needs to be fixed too).

Just to summarise - on ARM (PIPT / non-aliasing VIPT) there is I-cache
invalidation for user pages in update_mmu_cache() (it could actually be
in set_pte_at on SMP to avoid a race but that's for another thread). The
D-cache is flushed by this function only if the PG_arch_1 bit is set.
This bit is set in the ARM case by flush_dcache_page(), following the
advice in Documentation/cachetlb.txt.

With some drivers (those doing PIO) or subsystems (SCSI mass storage
over USB HCD), there is no call to flush_dcache_page() for page cache
pages, hence the ARM implementation of update_mmu_cache() doesn't flush
the D-cache (and only invalidating the I-cache doesn't help).

The viable solutions so far:

1. Implement a PIO mapping API similar to the DMA API which takes
care of the D-cache flushing. This means that PIO drivers would
need to be modified to use an API like pio_kmap()/pio_kunmap()
before writing to a page cache page.
2. Invert the meaning of PG_arch_1 to denote a clean page. This
means that by default newly allocated page cache pages are
considered dirty and even if there isn't a call to
flush_dcache_page(), update_mmu_cache() would flush the D-cache.
This is the PowerPC approach.

Option 2 above looks pretty appealing to me since it can be done in the
ARM code exclusively. I've done some tests and it indeed solves the
cache coherency with a rootfs on a USB stick. As Russell suggested, it
can be optimised to mark a page as clean when the DMA API is involved to
avoid duplicate flushing.

It was also suggested to add a PG_arch_2 flag which would keep track of
the I-cache status as well.

I can post a proposal to modify the cachetlb.txt document to reflect the
issues we currently have on ARM.

--
Catalin

==============================================================================
TOPIC: [PATCH] memcg: fix oom kill behavior.
http://groups.google.com/group/linux.kernel/t/9862560a1b380dda?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 9:20 am
From: Balbir Singh

* KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2010-03-02 11:58:34]:

> Brief Summary (for Andrew)
>
> - Nishimura reported my fix (one year ago)
> a636b327f731143ccc544b966cfd8de6cb6d72c6
> doesn't work well in some extreme situation.
>
> - David Rientjes said mem_cgroup_oom_called() is completely
> ugly and broken and.....
> And he tries to remove that in his patch set.
>
> Then, I wrote this as bugfix onto mmotm. This patch implements
> - per-memcg OOM lock as per-zone OOM lock
> - avoid to return -ENOMEM via mamcg's page fault path.
> ENOMEM causes unnecessary page_fault_out_of_memory().
> (Even if memcg hangs, there is no change from current behavior)
> - in addtion to MEMDIE thread, KILLED proceses go bypath memcg.
>
> I'm glad if this goes into 2.6.34 timeline (as bugfix). But I'm
> afraid this seems too big as bugfix...
>
> My plans for 2.6.35 are
> - oom-notifier for memcg (based on memcg threshold notifier)
> - oom-freezer (disable oom-kill) for memcg
> - better handling in extreme situation.
> And now, Andrea Righi works for dirty_ratio for memcg. We'll have
> something better in 2.6.35 kernels.
>
> This patch will HUNK with David's set. Then, if this hunks in mmotm,
> I'll rework.
>

Hi, Kamezawa-San,

Some review comments below.

> Tested on x86-64. Nishimura-san, could you test ?
>
> ==
> From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
>
> In current page-fault code,
>
> handle_mm_fault()
> -> ...
> -> mem_cgroup_charge()
> -> map page or handle error.
> -> check return code.
>
> If page fault's return code is VM_FAULT_OOM, page_fault_out_of_memory()
> is called. But if it's caused by memcg, OOM should have been already
> invoked.
> Then, I added a patch: a636b327f731143ccc544b966cfd8de6cb6d72c6
>
> That patch records last_oom_jiffies for memcg's sub-hierarchy and
> prevents page_fault_out_of_memory from being invoked in near future.
>
> But Nishimura-san reported that check by jiffies is not enough
> when the system is terribly heavy.
>
> This patch changes memcg's oom logic as.
> * If memcg causes OOM-kill, continue to retry.
> * remove jiffies check which is used now.

I like this very much!

> * add memcg-oom-lock which works like perzone oom lock.
> * If current is killed(as a process), bypass charge.
>
> Something more sophisticated can be added but this pactch does
> fundamental things.
> TODO:
> - add oom notifier
> - add permemcg disable-oom-kill flag and freezer at oom.
> - more chances for wake up oom waiter (when changing memory limit etc..)
>
> Changelog;
> - fixed per-memcg oom lock.
>
> Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> ---
> include/linux/memcontrol.h | 6 --
> mm/memcontrol.c | 109 +++++++++++++++++++++++++++++++++------------
> mm/oom_kill.c | 8 ---
> 3 files changed, 82 insertions(+), 41 deletions(-)
>
> Index: mmotm-2.6.33-Feb11/include/linux/memcontrol.h
> ===================================================================
> --- mmotm-2.6.33-Feb11.orig/include/linux/memcontrol.h
> +++ mmotm-2.6.33-Feb11/include/linux/memcontrol.h
> @@ -124,7 +124,6 @@ static inline bool mem_cgroup_disabled(v
> return false;
> }
>
> -extern bool mem_cgroup_oom_called(struct task_struct *task);
> void mem_cgroup_update_file_mapped(struct page *page, int val);
> unsigned long mem_cgroup_soft_limit_reclaim(struct zone *zone, int order,
> gfp_t gfp_mask, int nid,
> @@ -258,11 +257,6 @@ static inline bool mem_cgroup_disabled(v
> return true;
> }
>
> -static inline bool mem_cgroup_oom_called(struct task_struct *task)
> -{
> - return false;
> -}
> -
> static inline int
> mem_cgroup_inactive_anon_is_low(struct mem_cgroup *memcg)
> {
> Index: mmotm-2.6.33-Feb11/mm/memcontrol.c
> ===================================================================
> --- mmotm-2.6.33-Feb11.orig/mm/memcontrol.c
> +++ mmotm-2.6.33-Feb11/mm/memcontrol.c
> @@ -200,7 +200,7 @@ struct mem_cgroup {
> * Should the accounting and control be hierarchical, per subtree?
> */
> bool use_hierarchy;
> - unsigned long last_oom_jiffies;
> + atomic_t oom_lock;
> atomic_t refcnt;
>
> unsigned int swappiness;
> @@ -1234,32 +1234,77 @@ static int mem_cgroup_hierarchical_recla
> return total;
> }
>
> -bool mem_cgroup_oom_called(struct task_struct *task)
> +static int mem_cgroup_oom_lock_cb(struct mem_cgroup *mem, void *data)
> {
> - bool ret = false;
> - struct mem_cgroup *mem;
> - struct mm_struct *mm;
> + int *val = (int *)data;
> + int x;
>
> - rcu_read_lock();
> - mm = task->mm;
> - if (!mm)
> - mm = &init_mm;
> - mem = mem_cgroup_from_task(rcu_dereference(mm->owner));
> - if (mem && time_before(jiffies, mem->last_oom_jiffies + HZ/10))
> - ret = true;
> - rcu_read_unlock();
> - return ret;
> + x = atomic_inc_return(&mem->oom_lock);
> + if (x > *val)
> + *val = x;a

Use the max_t function here?
x = max_t(int, x, *val);

> + return 0;
> +}
> +/*
> + * Check OOM-Killer is already running under our hierarchy.
> + * If someone is running, return false.
> + */
> +static bool mem_cgroup_oom_lock(struct mem_cgroup *mem)
> +{
> + int check = 0;
> +
> + mem_cgroup_walk_tree(mem, &check, mem_cgroup_oom_lock_cb);
> +
> + if (check == 1)
> + return true;
> + return false;
> }
>
> -static int record_last_oom_cb(struct mem_cgroup *mem, void *data)
> +static int mem_cgroup_oom_unlock_cb(struct mem_cgroup *mem, void *data)
> {
> - mem->last_oom_jiffies = jiffies;
> + atomic_dec(&mem->oom_lock);
> return 0;
> }
>
> -static void record_last_oom(struct mem_cgroup *mem)
> +static void mem_cgroup_oom_unlock(struct mem_cgroup *mem)
> {
> - mem_cgroup_walk_tree(mem, NULL, record_last_oom_cb);
> + mem_cgroup_walk_tree(mem, NULL, mem_cgroup_oom_unlock_cb);
> +}
> +
> +static DEFINE_MUTEX(memcg_oom_mutex);
> +static DECLARE_WAIT_QUEUE_HEAD(memcg_oom_waitq);
> +
> +/*
> + * try to call OOM killer. returns false if we should exit memory-reclaim loop.
> + */
> +bool mem_cgroup_handle_oom(struct mem_cgroup *mem, gfp_t mask)
> +{
> + DEFINE_WAIT(wait);
> + bool locked;
> +
> + prepare_to_wait(&memcg_oom_waitq, &wait, TASK_INTERRUPTIBLE);
> + /* At first, try to OOM lock hierarchy under mem.*/
> + mutex_lock(&memcg_oom_mutex);
> + locked = mem_cgroup_oom_lock(mem);
> + mutex_unlock(&memcg_oom_mutex);
> +
> + if (locked) {
> + finish_wait(&memcg_oom_waitq, &wait);
> + mem_cgroup_out_of_memory(mem, mask);
> + } else {
> + schedule();
> + finish_wait(&memcg_oom_waitq, &wait);
> + }
> + mutex_lock(&memcg_oom_mutex);
> + mem_cgroup_oom_unlock(mem);
> + /* TODO: more fine grained waitq ? */
> + wake_up_all(&memcg_oom_waitq);

I was wondering if we should really wake up all? Shouldn't this be per
memcg? The waitq that is, since the check is per memcg, the wakeup
should also be per memcg.

> + mutex_unlock(&memcg_oom_mutex);
> +
> + if (test_thread_flag(TIF_MEMDIE) || fatal_signal_pending(current))
> + return false;
> + /* Give chance to dying process */
> + schedule_timeout(1);
> + return true;
> }
>
> /*
> @@ -1432,11 +1477,14 @@ static int __mem_cgroup_try_charge(struc
> struct res_counter *fail_res;
> int csize = CHARGE_SIZE;
>
> - if (unlikely(test_thread_flag(TIF_MEMDIE))) {
> - /* Don't account this! */
> - *memcg = NULL;
> - return 0;
> - }
> + /*
> + * Unlike gloval-vm's OOM-kill, we're not in memory shortage
> + * in system level. So, allow to go ahead dying process in addition to
> + * MEMDIE process.
> + */
> + if (unlikely(test_thread_flag(TIF_MEMDIE)
> + || fatal_signal_pending(current)))
> + goto bypass;
>
> /*
> * We always charge the cgroup the mm_struct belongs to.
> @@ -1549,11 +1597,15 @@ static int __mem_cgroup_try_charge(struc
> }
>
> if (!nr_retries--) {
> - if (oom) {
> - mem_cgroup_out_of_memory(mem_over_limit, gfp_mask);
> - record_last_oom(mem_over_limit);
> + if (!oom)
> + goto nomem;
> + if (mem_cgroup_handle_oom(mem_over_limit, gfp_mask)) {
> + nr_retries = MEM_CGROUP_RECLAIM_RETRIES;
> + continue;
> }
> - goto nomem;
> + /* When we reach here, current task is dying .*/
> + css_put(&mem->css);
> + goto bypass;
> }
> }
> if (csize > PAGE_SIZE)
> @@ -1572,6 +1624,9 @@ done:
> nomem:
> css_put(&mem->css);
> return -ENOMEM;
> +bypass:
> + *memcg = NULL;
> + return 0;
> }
>
> /*
> Index: mmotm-2.6.33-Feb11/mm/oom_kill.c
> ===================================================================
> --- mmotm-2.6.33-Feb11.orig/mm/oom_kill.c
> +++ mmotm-2.6.33-Feb11/mm/oom_kill.c
> @@ -599,13 +599,6 @@ void pagefault_out_of_memory(void)
> /* Got some memory back in the last second. */
> return;
>
> - /*
> - * If this is from memcg, oom-killer is already invoked.
> - * and not worth to go system-wide-oom.
> - */
> - if (mem_cgroup_oom_called(current))
> - goto rest_and_return;
> -
> if (sysctl_panic_on_oom)
> panic("out of memory from page fault. panic_on_oom is selected.\n");
>
> @@ -617,7 +610,6 @@ void pagefault_out_of_memory(void)
> * Give "p" a good chance of killing itself before we
> * retry to allocate memory.
> */
> -rest_and_return:
> if (!test_thread_flag(TIF_MEMDIE))
> schedule_timeout_uninterruptible(1);
> }
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

--
Three Cheers,
Balbir
--
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: Memory management woes - order 1 allocation failures
http://groups.google.com/group/linux.kernel/t/5fdc2e7e4a505944?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 9:30 am
From: Mel Gorman

On Mon, Mar 01, 2010 at 10:42:50AM +0900, KOSAKI Motohiro wrote:
> > AFAICT, even in the worst case, the latter call-site is well below 4K.
> > I have no idea of the tty one.
>
> afaik, tty_buffer_request_room() try to expand its buffer size for efficiency. but Its failure
> doesn't cause any user visible failure. probably we can mark it as NOWARN.
>
> In worst case, maximum tty buffer size is 64K, it can make allocation failure easily.
>
> Alan, Can you please tell us your mention?
>

(Added Greg as current tty maintainer)

For reasons that are not particularly clear to me, tty_buffer_alloc() is
called far more frequently in 2.6.33 than in 2.6.24. I instrumented the
function to print out the size of the buffers allocated, booted under
qemu and would just "cat /bin/ls" to see what buffers were allocated.
2.6.33 allocates loads, including high-order allocations. 2.6.24
appeared to allocate once and keep silent.

While there have been snags recently with respect to high-order
allocation failures in recent kernels, this might be one of the cases
where it's due to subsystems requesting high-order allocations more.

Anyone familiar with tty that might make a guess as to why it allocates
more aggressively?

--
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: linux-next: build failure after merge of the ext3 tree
http://groups.google.com/group/linux.kernel/t/0970bfd2b4d13c7b?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 9:30 am
From: Jan Kara

Hi,

On Tue 02-03-10 11:36:34, Stephen Rothwell wrote:
> After merging the ext3 tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> fs/jfs/jfs_xtree.c: In function 'xtSplitRoot':
> fs/jfs/jfs_xtree.c:1256: error: 'rec' undeclared (first use in this function)
>
> Caused by commit bff3333e868578990f6fe794a7cba0c74bd433ac ("dquot:
> cleanup space allocation / freeing routines").
>
> This is annoying ... this file system could be build tested on any
> architecture, so why wasn't it?
I'm sorry. It's my fault. I've modified Christoph's patch but I forgot to
enable JFS in the test build. Since this isn't the first time something
like this happened to me, I've changed the way I commit patches. They'll
first go to for_testing branch and after a build machine runs them through
allyesconfig and allmodconfig compiles they'll get moved to for_next
branch. So hopefully stupid mistakes like this one should be avoided for
future.

Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
--
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: libata: cache device select
http://groups.google.com/group/linux.kernel/t/d741a6a353f7ff1d?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 9:30 am
From: Alan Cox

> > - ata_dev_select(ap, qc->dev->devno, 1, 0);
> > + if (qc->dev->devno != ap->sff_selected)
> > + ata_dev_select(ap, qc->dev->devno, 1, 0);
> >
> > /* start the command */
> > switch (qc->tf.protocol) {
>
> My main worry here is that this logic excises the 150ms wait in
> ata_dev_select() that has been used effectively to allow ATAPI devices
> to "collect themselves" after waiting for idle, prior to command issuance.

It doesn't. You call it with wait = 1, can_sleep = 0 so it will never do
the 150ms magic delay here anyway (good job or it would kill us for
performance ;))

It does mean we don't do the device idle wait in that situation but there
are no code paths where we try to overlap commands by spinning on the
drive busy bit (again for obvious reasons)

Alan
--
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: omap updates for 2.6.34
http://groups.google.com/group/linux.kernel/t/0e292e3efc818822?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Mar 2 2010 9:30 am
From: Tony Lindgren

Hi Linus,

Please pull omap updates from:

git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-for-linus

Regards,

Tony

The following changes since commit ac0f6f927db539e03e1f3f61bcd4ed57d5cde7a9:
Linus Torvalds (1):
Merge branch 'for-linus' of master.kernel.org:/home/rmk/linux-2.6-arm

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-for-linus

Abhijit Pagare (13):
ARM: OMAP4: PM: OMAP4 essential basic initialisations.
ARM: OMAP4: PM: OMAP4 Power Domain Porting Related Clean-up.
ARM: OMAP4: PM: Add the Autogenerated OMAP4 specific power domain framework.
ARM: OMAP4: PM: Adapt the existing OMAP2/3 and common Power Domain Frameworks.
ARM: OMAP4: PM: Refine the APIs to support OMAP4 features.
ARM: OMAP4: PM: Make OMAP3 Clock-domain framework compatible for OMAP4.
ARM: OMAP4: PM: Modify Clock-domain interfaces for OMAP4 compatibility.
ARM: OMAP4: PM: Add the Autogenerated OMAP4 specific clock domain framework.
ARM: OMAP4: PM: Adapt the existing OMAP2/3 Clock Domain Frameworks.
ARM: OMAP4: PM: Refine the APIs to support OMAP4 features.
ARM: OMAP4 clock framework: Remove the checks preventing OMAP4 clockdomain validation
ARM: OMAP4 clock domains : Add the missing Clock Domain Structure
ARM: OMAP4 clock domain: Add check for avoiding dependency related update.

Adrian Hunter (10):
omap_hsmmc: Move gpio and regulator control from board file
omap: Rename mmc-twl4030 files to hsmmc
omap: Rename hsmmc symbols to reflect independence from twl4030
omap: Reconnect hsmmc context loss count
omap: RX51: Remux to pull eMMC lines down when powering off
omap_hsmmc: Allow for power saving without going off
omap_hsmmc: Fix disable timeouts
omap_hsmmc: Ensure regulator enable / disable are paired
omap_hsmmc: Allow for a shared VccQ
omap_hsmmc: allow compile without regulator framework

Ajay Kumar Gupta (2):
AM35x: Add missing GPIO mux config for EHCI port
AM35x: Enable OMAP_MUX in defconfig

Eero Nurkkala (1):
McBSP: OMAP3: Add sidetone feature

Enric Balletbo i Serra (8):
omap3: Add platform data for the twl4030_codec MFD on IGEP v2
omap3: Fix typo on IGEP v2 board
omap3: Add platform init code for EHCI driver on IGEP v2
omap3: Enable DSS2 for IGEP v2 board
omap3: Add support for flash on IGEP v2 board
omap3: SDRC: add timing data for Numonyx M65KxxxxAM
omap3: Use timing data for omap2_init_common_hw on IGEP v2
omap3: Update defconfig for IGEP v2 to allow new drivers andfeatures

Felipe Balbi (11):
omap1: mailbox: kill compile warning
omap2/3/4: mailbox: kill compile warning in mailbox.c
omap2/3/4: gpmc: kill compile warning
omap2/3/4: gpmc: avoid section definitions on headers
arm: omap: kill compile warning on board-4430-sdp.c
arm: omap: musb: ioremap only what's ours
omap: musb: remove unused data
arm: omap: musb: we can use clk framework
omap: musb: remove unused soft_con field
omap: musb: remove unused dma data
omap: musb: remove unnecessary return

Grazvydas Ignotas (3):
OMAP: pandora: add DSS2 support and related regulators
omap3: pandora: update regulator setup
omap3: pandora: update defconfig

Hiroshi DOYU (3):
omap iommu: cleanup iommu page address mask and definitions
omap: iommu: fix incorrect address for supersection 1st entry
omap iommu: fix incorrect address for largepage 1st entry

Ilkka Koskinen (1):
ASoC: OMAP-McBSP: ASoC interface for McBSP sidetone

Janusz Krzysztofik (4):
omap: McBSP: Use macros for all register read/write operations
omap: McBSP: Modify macros/functions API for easy cache access
omap: McBSP: Introduce caching in register write operations
omap: McBSP: Use cache when modifying individual register bits

Jarkko Nikula (1):
omap: i2c: Fix muxing for command line enabled bus

Jonas Zetterberg (2):
IGEPv2: Added WIFI support
IGEPv2: Use Red Led1 as Heartbeat if configured

Jorge Eduardo Candelaria (3):
OMAP4: IRQ: Add McPDM IRQ definition
ARM: OMAP4: Add McPDM base address
OMAP4: MCPDM: Register McPDM platform device

Kalle Jokiniemi (2):
OMAP3: cpuidle: Add valid field into C-state parameter passing
OMAP3: RX-51: Pass cpu idle parameters

Kevin Hilman (8):
OMAP: omap_device: optionally auto-adjust device activate/deactivate latencies
OMAP: hwmod: add API for slave idlemode setting
OMAP3: cpuidle: configure latencies/thresholds from board file
OMAP3: RX-51: support sleep indicator LEDs
OMAP: omap_device: add omap_device_is_valid()
OMAP: omap_device: when 'called from invalid state', print state
OMAP3: clock: use std _MASK suffix for CM_FCLKEN_IVA2 defines
OMAP2/3: PRCM: fix misc. compiler warnings

Ladislav Michl (2):
omap: convert boards to use physmap-flash
MTD: remove no longer used OMAP flash map

Lesly A M (1):
omap3: pm: Add T2 Keypad as a wakeup source

Maulik Mankad (4):
USB: Add empty functions in otg.h
omap: musb: Remove #ifdef from board-omap3evm.c
omap: musb: Pass board specific data from board file
omap: musb: Add USB support to 4430 SDP board file

Mike Rapoport (1):
omap3: cm-t35: add DSS2 display support

Mike Turquette (1):
OMAP3630: Clock: Workaround for DPLL HS divider limitation

Paul Walmsley (51):
OMAP3 clock: reorganize CK_* platform flags
OMAP clock: make the fixed divisor clock code available for all OMAPs
OMAP1 clock: convert armwdt_ck to use the fixed divisor recalc function
OMAP2/3 clkdm/pwrdm: move wkdep/sleepdep handling from pwrdm to clkdm
OMAP2/3 clockdomains: split shared structures so usecounting works
OMAP2 clockdomain: modem clockdomain is only present on OMAP2430
OMAP clockdomain/powerdomain: remove runtime register/unregister
OMAP clockdomains: add usecounting for wakeup and sleep dependencies
OMAP powerdomain/PM: use symbolic constants for the max number of power states
OMAP powerdomain: rearrange struct powerdomain to save some memory
OMAP powerdomain: remove pwrdm_clk_state_switch
OMAP clockdomain/powerdomain: improve documentation
OMAP3 clock: move OMAP3-specific DPLL functions to dpll3xxx.c
OMAP2/3/4 clock: move DPLL clock functions into mach-omap2/clkt_dpll.c
OMAP2/3/4 clock: move clksel clock functions into mach-omap2/clkt_clksel.c
OMAP2 clock: move all static functions to the top of the file
OMAP2/3/4 clock: combine all omap2_clk_functions
OMAP2xxx clock: move the DPLL+CORE composite clock code into mach-omap2/clkt2xxx_dpllcore.c
OMAP2xxx clock: move the DVFS virtual clock code into mach-omap2/clkt2xxx_virt_prcm_set.c
OMAP2xxx clock: move the APLL clock code into mach-omap2/clkt2xxx_apll.c
OMAP2xxx clock: move osc_clk code into mach-omap2/clkt2xxx_osc.c
OMAP2xxx clock: move sys_clk code into mach-omap2/clkt2xxx_sys.c
OMAP2 clock: don't compile OMAP2430-only functions on non-2430 builds
OMAP3 clock: split out DPLL3 M2 divider functions into mach-omap2/clkt34xx_dpll3m2.c
OMAP2/3 clock: clean up omap*_clk_arch_init()
OMAP2/3 clock: remove unnecessary includes and clean up header
OMAP2/3/4 clock: omap2_clk_prepare_for_reboot() is OMAP2xxx-only
OMAP3 DPLL: reorganize static functions
OMAP clock: resolve all remaining sparse warnings
OMAP2/3/4 clock: rename and clean the omap2_clk_init() functions
OMAP2+ powerdomains/clockdomains: prepare for multi-OMAP configs
OMAP2/3/4 clock: fix DPLL multiplier value errors; also copyrights, includes, documentation
OMAP4 clock: drop the CLOCK_IN_OMAP4430 clock flag
OMAP2xxx clock: GFX functional clock rates are not independently changeable
OMAP2xxx clock: drop DELAYED_APP flag from non-clksel clocks
OMAP2 clock: drop CONFIG_PARTICIPANT clock flag
OMAP clock: compress clock flags down to a u8
OMAP clock: drop .id field; ensure each clock has a unique name
OMAP3/4 clock: split into per-chip family files
OMAP2 clock: split OMAP2420, OMAP2430 clock data into their own files
OMAP2430 clock: make func_96m_ck parent-selectable
OMAP2 clock: drop DELAYED_APP clock flag
OMAP clock: drop RATE_FIXED clock flag
OMAP4 clock: drop the ALWAYS_ENABLED clock flag
OMAP clock: add omap_clk_get_by_name() for use by OMAP hwmod core code
OMAP hwmod: convert hwmod to use hardware clock names rather than clkdev dev+con
OMAP hwmod: convert header files with static allocations into C files
OMAP hwmod: add hwmod class support
OMAP clockdomain: if no autodeps exist, don't try to add or remove them
OMAP2/3 clock: combine OMAP2 & 3 boot-time MPU rate change code
OMAP2+ clock: revise omap2_clk_{disable,enable}()

Rajendra Nayak (3):
OMAP4: PRCM: Define shift macros as n instead of 1 << n
OMAP3: PM: add scratchpad locking function
OMAP4: clock: Rename leaf clock nodes to end with a _ick or _fck

Ranjith Lohithakshan (4):
AM35xx: Add AM35xx specific control module registers
AM35xx: Clock table updates for AM3505/17
OMAP2/3 clock: Extend find_idlest() to pass back idle state value
AM35xx: Add clock support for new modules on AM35xx

Richard Woodruff (1):
OMAP3 clock: introduce DPLL4 Jtype

Rob Clark (1):
omap2/3/4: mailbox: use dedicated work queue for handling mailbox rx interrupt

Sanjeev Premi (6):
omap3evm: Add mux settings for keypad
omap3evm: Fixes after moving to matrix_keypad
omap3evm: Configure GPIO175 for touchscreen PEN_IRQ
OMAP3EVM: PM: Update defconfig
OMAP3: cpuidle: Update statistics for correct state
OMAP3 clock: Check return values for clk_get()

Santosh Shilimkar (12):
omap4: multi-omap: Allow build to work
omap3/4: uart: fix full-fifo write abort
omap2/3/4: ioremap omap_globals module
omap4: sdma: Enable the idle modes on omap4
omap: sdma: Limit the secure reserve channel fix for omap3
omap4: Fix omap_type() for omap4
omap3/4: Remove overlapping mapping of L4_WKUP io space
omap4: Add auto-generated irq and dma headers
omap4: Use dma line defines from dma-44xx.h
omap4: Use irq line defines from irq-44xx.h
OMAP4: clock: Add dummy clock nodes for interface clocks
OMAP4: clock: Remove clock hacks from timer-gp.c

Sriram (2):
AM3517 EVM: Enable I2C support
AM3517 EVM: correct typo - tca6416 mispelt as tca6516

Suman Anna (2):
omap: mailbox: correct OMAP4 reset logic
omap: mailbox: correct OMAP4 SIDLEMODE logic

Tero Kristo (2):
OMAP3: PM: Added support for L2 aux ctrl register save and restore
OMAP3: Clock: Added IDLEST definitions for SGX

Thara Gopinath (5):
OMAP2/3 PM: Adding powerdomain APIs for reading the next logic and mem state
OMAP3 PM: Defining .pwrsts_logic_ret field for core power domain structure
OMAP3 PM: Adding counters for power domain logic off and mem off during retention.
OMAP3: hwmod: support to specify the offset position of various SYSCONFIG register bits.
OMAP: HWMOD: Add support for early device register into omap device layer

Thomas Weber (2):
Add minimal support for DevKit8000
Add devkit8000_defconfig

Tony Lindgren (32):
Merge branch 'for_2.6.34_4f4e65_a' of git://git.pwsan.com/linux-2.6 into omap-for-linus
Merge branch 'omap-fixes-for-linus' into omap-for-linus
Merge branch 'for-tony' of git://gitorious.org/linux-omap-dss2/linux into omap-for-linus
omap: Clean the serial port defines
omap: Make uncompress code and DEBUG_LL code generic
omap: Remove old DEBUG_LL serial port options
Merge branch 'debug-ll' into omap-for-linus
omap2/3: Make get_irqnr_and_base common for mach-omap2 multiboot
omap2/3: Multiboot compile fixes to compile in omap2 and omap3
omap: Fix dmtimer.c for multi-omap boot
omap2/3/4: Fix omap2_map_common_io for multi-omap
omap2/3/4: Fix mbox init for multi-omap
omap2: Convert ARCH_OMAP24XX to ARCH_OMAP2
omap3: Replace ARCH_OMAP34XX with ARCH_OMAP3
omap2/3/4: Replace orred CONFIG_ARCH_OMAP2/3/4 with CONFIG_ARCH_OMAP2PLUS
omap2/3: Fix initcalls for multi-omap
omap2/3: Update omap3_defconfig to build in all the 2420 based boards
omap: Move multi-omap ifdeffery into it's own header file
omap2/3/4: Clean up defines for entry-macro.S
omap4: Use get_irqnr_preamble
omap2/3/4: Clean up entry-macro.s for adding support for omap4 multiboot
omap2/3/4: Allow booting omap4 with multi-omap configuration
omap3/4: Fix compile for multi-omap for clkops_noncore_dpll_ops
omap: Fix gpio.c for multi-omap for omap4
omap2/3/4: Fix mach-omap2/serial.c for multiboot
omap2/3/4: Add omap4 into omap3_defconfig
omap3: Clean-up for omap_mux_init
Merge branch 'omap-fixes-for-linus' into omap-for-linus
Merge branch 'pm-2.6.34' of git://git.kernel.org/.../khilman/linux-omap-pm into omap-for-linus
Merge branch 'for_2.6.34_b' of git://git.pwsan.com/linux-2.6 into omap-for-linus
omap2: Initialize Menelaus and MMC for N8X0
Merge with mainline to remove plat-omap/Kconfig conflict

Vaibhav Hiremath (8):
OMAP: Enable DSS2 for OMAP3EVM board
OMAP: AM3517: Enable DSS2 for AM3517EVM board
AM35xx: Introduce am35xx.h file
AM35xx: Add AM35xx intr_clr & sw_rst cntrl reg bit definition
AM35xx: Update irq.h for AM35xx IPSS module interrupts
AM3517: Enable basic I2C Support
AM3517: Enable RTC driver support for AM3517EVM
AM3517: Enable I2C-GPIO Expander driver support for AM3517EVM

Vimal Singh (3):
omap2/3/4: Introducing 'gpmc-nand.c' for GPMC specific NAND init
omap3: SDP: Introducing 'board-sdp-flash.c' for flash init
omap3: Add support for flash on 3430SDP board

Vimarsh Zutshi (1):
OMAP3: clock: add capability to change rate of dpll4_m5_ck_3630

Vishwanath BS (3):
OMAP3 clock: Remove FreqSel for 3630
OMAP3 clock: Introduce 3630 DPLL4 HSDivider changes
OMAP3 clock: add support for 192Mhz DPLL4M2 output

manjugk manjugk (1):
Zoom3: Defconfig update

vikram pandita (2):
omap2/3/4: serial: fix coding style indentaion
omap: zoom3: enable ehci support

arch/arm/configs/am3517_evm_defconfig | 43 +-
arch/arm/configs/devkit8000_defconfig | 1889 ++++++++++++++++++++
arch/arm/configs/igep0020_defconfig | 525 ++++---
arch/arm/configs/omap3_defconfig | 180 ++-
arch/arm/configs/omap3_evm_defconfig | 6 +-
arch/arm/configs/omap3_pandora_defconfig | 678 ++++++--
arch/arm/configs/omap_4430sdp_defconfig | 7 +-
arch/arm/configs/omap_zoom3_defconfig | 6 +-
arch/arm/configs/rx51_defconfig | 4 +-
arch/arm/mach-omap1/Makefile | 2 +-
arch/arm/mach-omap1/board-fsample.c | 9 +-
arch/arm/mach-omap1/board-h2.c | 9 +-
arch/arm/mach-omap1/board-h3.c | 9 +-
arch/arm/mach-omap1/board-innovator.c | 9 +-
arch/arm/mach-omap1/board-osk.c | 9 +-
arch/arm/mach-omap1/board-palmte.c | 9 +-
arch/arm/mach-omap1/board-palmtt.c | 9 +-
arch/arm/mach-omap1/board-palmz71.c | 10 +-
arch/arm/mach-omap1/board-perseus2.c | 9 +-
arch/arm/mach-omap1/board-sx1.c | 11 +-
arch/arm/mach-omap1/board-voiceblue.c | 9 +-
arch/arm/mach-omap1/clock.c | 25 +-
arch/arm/mach-omap1/clock_data.c | 44 +-
arch/arm/mach-omap1/devices.c | 2 +-
arch/arm/mach-omap1/flash.c | 33 +
arch/arm/mach-omap1/i2c.c | 6 +-
arch/arm/mach-omap1/include/mach/debug-macro.S | 88 +-
arch/arm/mach-omap1/mailbox.c | 9 +-
arch/arm/mach-omap1/mcbsp.c | 16 +-
arch/arm/mach-omap1/serial.c | 6 +-
arch/arm/mach-omap2/Kconfig | 61 +-
arch/arm/mach-omap2/Makefile | 87 +-
arch/arm/mach-omap2/board-2430sdp.c | 23 +-
arch/arm/mach-omap2/board-3430sdp.c | 147 ++-
arch/arm/mach-omap2/board-3630sdp.c | 4 +-
arch/arm/mach-omap2/board-4430sdp.c | 18 +-
arch/arm/mach-omap2/board-am3517evm.c | 237 +++-
arch/arm/mach-omap2/board-apollon.c | 2 +-
arch/arm/mach-omap2/board-cm-t35.c | 255 +++-
arch/arm/mach-omap2/board-devkit8000.c | 697 ++++++++
arch/arm/mach-omap2/board-generic.c | 2 +-
arch/arm/mach-omap2/board-h4.c | 9 +-
arch/arm/mach-omap2/board-igep0020.c | 285 +++-
arch/arm/mach-omap2/board-ldp.c | 16 +-
arch/arm/mach-omap2/board-n8x0.c | 447 +++++-
arch/arm/mach-omap2/board-omap3beagle.c | 16 +-
arch/arm/mach-omap2/board-omap3evm.c | 299 +++-
arch/arm/mach-omap2/board-omap3pandora.c | 196 ++-
arch/arm/mach-omap2/board-omap3touchbook.c | 16 +-
arch/arm/mach-omap2/board-overo.c | 16 +-
arch/arm/mach-omap2/board-rx51-peripherals.c | 63 +-
arch/arm/mach-omap2/board-rx51.c | 54 +-
arch/arm/mach-omap2/board-sdp-flash.c | 272 +++
arch/arm/mach-omap2/board-zoom-peripherals.c | 23 +-
arch/arm/mach-omap2/board-zoom2.c | 2 +-
arch/arm/mach-omap2/board-zoom3.c | 18 +-
arch/arm/mach-omap2/clkt2xxx_apll.c | 122 ++
arch/arm/mach-omap2/clkt2xxx_dpllcore.c | 173 ++
arch/arm/mach-omap2/clkt2xxx_osc.c | 62 +
arch/arm/mach-omap2/clkt2xxx_sys.c | 50 +
arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c | 254 +++
arch/arm/mach-omap2/clkt34xx_dpll3m2.c | 121 ++
arch/arm/mach-omap2/clkt_clksel.c | 409 +++++
arch/arm/mach-omap2/clkt_dpll.c | 386 ++++
arch/arm/mach-omap2/clock.c | 1029 +++---------
arch/arm/mach-omap2/clock.h | 50 +-
.../{clock2xxx_data.c => clock2420_data.c} | 705 ++------
arch/arm/mach-omap2/clock2430.c | 59 +
.../{clock2xxx_data.c => clock2430_data.c} | 643 ++-----
arch/arm/mach-omap2/clock2xxx.c | 599 +------
arch/arm/mach-omap2/clock2xxx.h | 31 +-
arch/arm/mach-omap2/clock34xx.c | 261 +---
arch/arm/mach-omap2/clock34xx.h | 19 +-
arch/arm/mach-omap2/clock3517.c | 124 ++
arch/arm/mach-omap2/clock3517.h | 14 +
arch/arm/mach-omap2/clock36xx.c | 72 +
arch/arm/mach-omap2/clock36xx.h | 13 +
arch/arm/mach-omap2/clock3xxx.c | 104 ++
arch/arm/mach-omap2/clock3xxx.h | 21 +
.../{clock34xx_data.c => clock3xxx_data.c} | 888 +++++++---
arch/arm/mach-omap2/clock44xx.c | 33 -
arch/arm/mach-omap2/clock44xx.h | 13 +-
arch/arm/mach-omap2/clock44xx_data.c | 734 ++++----
arch/arm/mach-omap2/clockdomain.c | 788 +++++++--
arch/arm/mach-omap2/clockdomains.h | 672 +++++++-
arch/arm/mach-omap2/clockdomains44xx.h | 250 +++
arch/arm/mach-omap2/cm-regbits-34xx.h | 28 +-
arch/arm/mach-omap2/cm-regbits-44xx.h | 536 +++---
arch/arm/mach-omap2/cm.h | 8 +-
arch/arm/mach-omap2/control.c | 6 +-
arch/arm/mach-omap2/cpuidle34xx.c | 226 ++-
arch/arm/mach-omap2/devices.c | 45 +-
arch/arm/mach-omap2/{dpll.c => dpll3xxx.c} | 191 ++-
arch/arm/mach-omap2/emu.c | 3 +
arch/arm/mach-omap2/gpmc-nand.c | 139 ++
arch/arm/mach-omap2/gpmc.c | 6 +-
arch/arm/mach-omap2/hsmmc.c | 266 +++
arch/arm/mach-omap2/{mmc-twl4030.h => hsmmc.h} | 14 +-
arch/arm/mach-omap2/i2c.c | 6 +-
arch/arm/mach-omap2/id.c | 6 +
arch/arm/mach-omap2/include/mach/am35xx.h | 26 +
arch/arm/mach-omap2/include/mach/board-sdp.h | 21 +
arch/arm/mach-omap2/include/mach/debug-macro.S | 130 ++-
arch/arm/mach-omap2/include/mach/entry-macro.S | 128 ++-
arch/arm/mach-omap2/io.c | 107 +-
arch/arm/mach-omap2/mailbox.c | 47 +-
arch/arm/mach-omap2/mcbsp.c | 24 +-
arch/arm/mach-omap2/mmc-twl4030.c | 542 ------
arch/arm/mach-omap2/mux.c | 52 +-
arch/arm/mach-omap2/mux.h | 2 +-
arch/arm/mach-omap2/omap_hwmod.c | 315 +++-
.../{omap_hwmod_2420.h => omap_hwmod_2420_data.c} | 38 +-
.../{omap_hwmod_2430.h => omap_hwmod_2430_data.c} | 38 +-
arch/arm/mach-omap2/omap_hwmod_34xx.h | 168 --
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 181 ++
arch/arm/mach-omap2/omap_hwmod_common_data.c | 68 +
arch/arm/mach-omap2/omap_hwmod_common_data.h | 24 +
arch/arm/mach-omap2/opp2xxx.h | 5 +
arch/arm/mach-omap2/pm-debug.c | 25 +-
arch/arm/mach-omap2/pm.h | 20 +
arch/arm/mach-omap2/pm24xx.c | 54 +-
arch/arm/mach-omap2/pm34xx.c | 43 +-
arch/arm/mach-omap2/powerdomain.c | 776 +++-----
arch/arm/mach-omap2/powerdomains.h | 134 +-
arch/arm/mach-omap2/powerdomains24xx.h | 91 +-
arch/arm/mach-omap2/powerdomains34xx.h | 159 +--
arch/arm/mach-omap2/powerdomains44xx.h | 310 ++++
arch/arm/mach-omap2/prcm-common.h | 9 +
arch/arm/mach-omap2/prcm.c | 114 +-
arch/arm/mach-omap2/prm-regbits-44xx.h | 1010 ++++++------
arch/arm/mach-omap2/prm.h | 17 +-
arch/arm/mach-omap2/sdram-numonyx-m65kxxxxam.h | 51 +
arch/arm/mach-omap2/sdrc.c | 11 +-
arch/arm/mach-omap2/serial.c | 80 +-
arch/arm/mach-omap2/sleep34xx.S | 61 +-
arch/arm/mach-omap2/timer-gp.c | 5 -
arch/arm/mach-omap2/timer-mpu.c | 2 +-
arch/arm/mach-omap2/usb-musb.c | 82 +-
arch/arm/plat-omap/Kconfig | 57 +-
arch/arm/plat-omap/clock.c | 52 +-
arch/arm/plat-omap/common.c | 69 +-
arch/arm/plat-omap/devices.c | 39 +-
arch/arm/plat-omap/dma.c | 10 +-
arch/arm/plat-omap/dmtimer.c | 126 +-
arch/arm/plat-omap/gpio.c | 302 ++--
arch/arm/plat-omap/i2c.c | 18 +-
arch/arm/plat-omap/include/plat/clkdev_omap.h | 26 +-
arch/arm/plat-omap/include/plat/clock.h | 100 +-
arch/arm/plat-omap/include/plat/clockdomain.h | 98 +-
arch/arm/plat-omap/include/plat/common.h | 24 +-
arch/arm/plat-omap/include/plat/control.h | 40 +-
arch/arm/plat-omap/include/plat/cpu.h | 92 +-
arch/arm/plat-omap/include/plat/dma-44xx.h | 147 ++
arch/arm/plat-omap/include/plat/dma.h | 86 +-
arch/arm/plat-omap/include/plat/flash.h | 16 +
arch/arm/plat-omap/include/plat/gpmc.h | 4 +-
arch/arm/plat-omap/include/plat/i2c.h | 5 +-
arch/arm/plat-omap/include/plat/io.h | 42 +-
arch/arm/plat-omap/include/plat/irqs-44xx.h | 144 ++
arch/arm/plat-omap/include/plat/irqs.h | 102 +-
arch/arm/plat-omap/include/plat/mcbsp.h | 72 +-
arch/arm/plat-omap/include/plat/memory.h | 3 +-
arch/arm/plat-omap/include/plat/menelaus.h | 2 +-
arch/arm/plat-omap/include/plat/mmc.h | 35 +-
arch/arm/plat-omap/include/plat/multi.h | 94 +
arch/arm/plat-omap/include/plat/mux.h | 2 +-
arch/arm/plat-omap/include/plat/nand.h | 10 +-
arch/arm/plat-omap/include/plat/omap16xx.h | 74 +-
arch/arm/plat-omap/include/plat/omap24xx.h | 6 +-
arch/arm/plat-omap/include/plat/omap34xx.h | 6 +-
arch/arm/plat-omap/include/plat/omap44xx.h | 3 +
arch/arm/plat-omap/include/plat/omap_device.h | 11 +-
arch/arm/plat-omap/include/plat/omap_hwmod.h | 138 ++-
arch/arm/plat-omap/include/plat/powerdomain.h | 95 +-
arch/arm/plat-omap/include/plat/prcm.h | 11 +-
arch/arm/plat-omap/include/plat/serial.h | 70 +-
arch/arm/plat-omap/include/plat/uncompress.h | 181 ++-
arch/arm/plat-omap/include/plat/usb.h | 11 +-
arch/arm/plat-omap/io.c | 4 -
arch/arm/plat-omap/iommu.c | 6 +-
arch/arm/plat-omap/iopgtable.h | 50 +-
arch/arm/plat-omap/mailbox.c | 8 +-
arch/arm/plat-omap/mcbsp.c | 774 ++++++--
arch/arm/plat-omap/omap_device.c | 102 +-
arch/arm/plat-omap/sram.c | 2 +-
drivers/char/hw_random/Kconfig | 2 +-
drivers/mfd/Kconfig | 2 +-
drivers/mmc/host/omap_hsmmc.c | 400 ++++-
drivers/mtd/maps/Kconfig | 9 -
drivers/mtd/maps/Makefile | 1 -
drivers/mtd/maps/omap_nor.c | 188 --
drivers/mtd/nand/omap2.c | 35 +-
drivers/net/smc911x.h | 4 +-
drivers/spi/Kconfig | 2 +-
drivers/spi/omap2_mcspi.c | 2 +-
drivers/usb/Kconfig | 2 +-
drivers/usb/host/ehci-hcd.c | 2 +-
drivers/usb/musb/Kconfig | 6 +-
drivers/usb/musb/musb_core.c | 2 +-
drivers/usb/musb/musb_core.h | 2 +-
drivers/w1/masters/Kconfig | 2 +-
drivers/watchdog/Kconfig | 2 +-
include/linux/usb/musb.h | 3 +
include/linux/usb/otg.h | 10 +
sound/soc/omap/omap-mcbsp.c | 144 ++-
sound/soc/omap/omap-mcbsp.h | 4 +-
206 files changed, 17707 insertions(+), 8571 deletions(-)
create mode 100644 arch/arm/configs/devkit8000_defconfig
create mode 100644 arch/arm/mach-omap1/flash.c
create mode 100644 arch/arm/mach-omap2/board-devkit8000.c
create mode 100644 arch/arm/mach-omap2/board-sdp-flash.c
create mode 100644 arch/arm/mach-omap2/clkt2xxx_apll.c
create mode 100644 arch/arm/mach-omap2/clkt2xxx_dpllcore.c
create mode 100644 arch/arm/mach-omap2/clkt2xxx_osc.c
create mode 100644 arch/arm/mach-omap2/clkt2xxx_sys.c
create mode 100644 arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
create mode 100644 arch/arm/mach-omap2/clkt34xx_dpll3m2.c
create mode 100644 arch/arm/mach-omap2/clkt_clksel.c
create mode 100644 arch/arm/mach-omap2/clkt_dpll.c
copy arch/arm/mach-omap2/{clock2xxx_data.c => clock2420_data.c} (72%)
create mode 100644 arch/arm/mach-omap2/clock2430.c
rename arch/arm/mach-omap2/{clock2xxx_data.c => clock2430_data.c} (75%)
create mode 100644 arch/arm/mach-omap2/clock3517.c
create mode 100644 arch/arm/mach-omap2/clock3517.h
create mode 100644 arch/arm/mach-omap2/clock36xx.c
create mode 100644 arch/arm/mach-omap2/clock36xx.h
create mode 100644 arch/arm/mach-omap2/clock3xxx.c
create mode 100644 arch/arm/mach-omap2/clock3xxx.h
rename arch/arm/mach-omap2/{clock34xx_data.c => clock3xxx_data.c} (80%)
delete mode 100644 arch/arm/mach-omap2/clock44xx.c
create mode 100644 arch/arm/mach-omap2/clockdomains44xx.h
rename arch/arm/mach-omap2/{dpll.c => dpll3xxx.c} (85%)
create mode 100644 arch/arm/mach-omap2/gpmc-nand.c
create mode 100644 arch/arm/mach-omap2/hsmmc.c
rename arch/arm/mach-omap2/{mmc-twl4030.h => hsmmc.h} (63%)
create mode 100644 arch/arm/mach-omap2/include/mach/am35xx.h
create mode 100644 arch/arm/mach-omap2/include/mach/board-sdp.h
delete mode 100644 arch/arm/mach-omap2/mmc-twl4030.c
rename arch/arm/mach-omap2/{omap_hwmod_2420.h => omap_hwmod_2420_data.c} (82%)
rename arch/arm/mach-omap2/{omap_hwmod_2430.h => omap_hwmod_2430_data.c} (83%)
delete mode 100644 arch/arm/mach-omap2/omap_hwmod_34xx.h
create mode 100644 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
create mode 100644 arch/arm/mach-omap2/omap_hwmod_common_data.c
create mode 100644 arch/arm/mach-omap2/omap_hwmod_common_data.h
create mode 100644 arch/arm/mach-omap2/powerdomains44xx.h
create mode 100644 arch/arm/mach-omap2/sdram-numonyx-m65kxxxxam.h
create mode 100644 arch/arm/plat-omap/include/plat/dma-44xx.h
create mode 100644 arch/arm/plat-omap/include/plat/flash.h
create mode 100644 arch/arm/plat-omap/include/plat/irqs-44xx.h
create mode 100644 arch/arm/plat-omap/include/plat/multi.h
--
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/

==============================================================================

You received this message because you are subscribed to the Google Groups "linux.kernel"
group.

To post to this group, visit http://groups.google.com/group/linux.kernel?hl=en

To unsubscribe from this group, send email to linux.kernel+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/linux.kernel/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

twitter

Tuesday, March 2, 2010

linux.kernel - 25 new messages in 23 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts