Hi,
sorry for the delay
On Mon, Jan 28, 2013 at 07:06:56PM +0530, Vivek Gautam wrote:
> Hi Felipe,
>
>
> On Mon, Jan 28, 2013 at 5:15 PM, Felipe Balbi wrote:
> > On Mon, Jan 28, 2013 at 05:12:26PM +0530, Vivek Gautam wrote:
> >> The current code in the dwc3 probe effectively disables runtime p
From: Magnus Damm
This patch adds a driver for external IRQ pins connected
to the IRQC hardware block on recent SoCs from Renesas.
The IRQC hardware block is used together with more
recent ARM based SoCs using the GIC. As usual the GIC
requires external IRQ trigger setup somewhere else
which in
Hi, all!
I've implemented low limits for memory cgroups. The primary goal was to add an
ability
to protect some memory from reclaiming without using mlock(). A kind of "soft
mlock()".
I think this patch will be helpful when it's necessary to protect production
processes from
memory-wasting ba
On Mon, Feb 18, 2013 at 11:28:34PM +0900, Magnus Damm wrote:
> From: Magnus Damm
>
> This patch adds a driver for external IRQ pins connected
> to the INTC block on recent SoCs from Renesas.
>
So how exactly does this interact with the existing sh_intc code? Or is
there some reason why you have
>
> this patch seems to be oopsing on my x86 32-bit machine on bootup, pic
> attached.
>
> .config attached.
>
> It looks to me like the weak bit isn't working so well
>
> if (platform_sysrq_reset_seq) {
> for (i = 0; i < ARRAY_SIZE(sysrq_reset_seq); i++) {
>
On 26 February 2013 18:43, Frederic Weisbecker wrote:
> 2013/2/26 Vincent Guittot :
>> On 26 February 2013 14:16, Frederic Weisbecker wrote:
>>> 2013/2/22 Vincent Guittot :
I wanted to avoid having to use the sd pointer for testing NOHZ_IDLE
flag because it occurs each time we go into i
On Wed, Feb 27, 2013 at 5:23 PM, Paul Mundt wrote:
> On Mon, Feb 18, 2013 at 11:28:34PM +0900, Magnus Damm wrote:
>> From: Magnus Damm
>>
>> This patch adds a driver for external IRQ pins connected
>> to the INTC block on recent SoCs from Renesas.
>>
> So how exactly does this interact with the e
On Wed, Feb 27, 2013 at 05:15:01PM +0900, Magnus Damm wrote:
> From: Magnus Damm
>
> This patch adds a driver for external IRQ pins connected
> to the IRQC hardware block on recent SoCs from Renesas.
>
> The IRQC hardware block is used together with more
> recent ARM based SoCs using the GIC. As
Hi Simon,
On Tue, Feb 26, 2013 at 09:13:06PM -0800, Simon Glass wrote:
> Hi Samuel,
>
> On Mon, Feb 25, 2013 at 2:08 PM, Simon Glass wrote:
> > The ChromeOS Embedded Controller (EC) is an Open Source EC implementation
> > used on ARM and Intel Chromebooks. Current implementations use a Cortex-M3
On Wed, Feb 27 2013, Roman Gushchin wrote:
> Hi, all!
>
> I've implemented low limits for memory cgroups. The primary goal was to add
> an ability
> to protect some memory from reclaiming without using mlock(). A kind of "soft
> mlock()".
>
> I think this patch will be helpful when it's necessa
On Wed, Feb 27, 2013 at 05:35:51PM +0900, Magnus Damm wrote:
> On Wed, Feb 27, 2013 at 5:23 PM, Paul Mundt wrote:
> > So how exactly does this interact with the existing sh_intc code? Or is
> > there some reason why you have opted to bypass it in order to implement a
> > simplified reduced-functio
Hi Felipe,
On Wed, Feb 27, 2013 at 1:36 PM, Felipe Balbi wrote:
> Hi,
>
> sorry for the delay
>
That's alright ;-)
> On Mon, Jan 28, 2013 at 07:06:56PM +0530, Vivek Gautam wrote:
>> Hi Felipe,
>>
>>
>> On Mon, Jan 28, 2013 at 5:15 PM, Felipe Balbi wrote:
>> > On Mon, Jan 28, 2013 at 05:12:26P
On Tue, Feb 26, 2013 at 11:48:18AM +0200, Terje Bergström wrote:
> On 25.02.2013 17:24, Thierry Reding wrote:
> > On Tue, Jan 15, 2013 at 01:43:59PM +0200, Terje Bergstrom wrote:
[...]
> >> +/*
> >> + * Start timer for a buffer submition that has completed yet.
> >
> > "submission". And I don't un
于 2013年02月27日 16:45, Vladimir Kondratiev 写道:
> On Wednesday, February 27, 2013 02:55:06 PM Chen Gang wrote:
>>
>> When make with EXTRA_CFLAGS=-W, it will report error.
>> so give a check in Makefile.
>>
>> Signed-off-by: Chen Gang
>> ---
>> drivers/net/wireless/ath/wil6210/Makefile |4 +++
Hello Dmitry,
First of all, thanks for your comments.
On 02/26/2013 11:28 PM, Dmitry Torokhov wrote:
> On Tue, Feb 26, 2013 at 10:03:15AM +0100, Samuel Iglesias Gonsalvez wrote:
>> put_device() must be called after device_register() fails,
>> since device_register() always initializes the refcoun
David Miller writes:
>> Applied, thanks Glen.
>
> Actually, I had to revert, this doesn't even compile against
> current sources:
>
> CC [M] drivers/net/usb/asix_devices.o
> drivers/net/usb/asix_devices.c:941:14: error: ‘asix_rx_fixup’ undeclared here
> (not in a function)
> make[1]: *** [dri
On Wed, Feb 27, 2013 at 1:22 AM, Mimi Zohar wrote:
> On Tue, 2013-02-26 at 20:34 +, Al Viro wrote:
>> On Tue, Feb 26, 2013 at 02:32:08PM -0500, Mimi Zohar wrote:
>> > Before anything gets access to the file, the file needs to be measured,
>> > appraised, and/or audited, based on policy. If IM
On Tue, 2013-02-26 at 20:02 -0800, Greg KH wrote:
> On Tue, Feb 26, 2013 at 09:35:14AM -0800, Greg KH wrote:
> > On Mon, Feb 25, 2013 at 07:45:45PM -0800, Greg KH wrote:
> > > On Mon, Feb 25, 2013 at 02:32:43PM -0800, Greg KH wrote:
> > > > On Mon, Feb 25, 2013 at 04:06:02PM +1000, Dave Airlie wrot
Hi Darrick,
> -Original Message-
> From: Darrick J. Wong [mailto:darrick.w...@oracle.com]
> Sent: Wednesday, February 27, 2013 3:15 AM
> To: Sanoj Unnikrishnan
> Cc: OS Engineering; Greg Kroah-Hartman; LKML; Jens Axboe; 王金浦; Amit
> Kale; dm-de...@redhat.com; koverstr...@google.com; thorn.
David Howells redhat.com> writes:
>
>
> Florian Weimer deneb.enyo.de> wrote:
>
> > Seriously, folks, can we go back one step and discuss what problem you
> > are trying to solve? Is it about allowing third-party kernel modules
> > in an environment which does not allow unsigned ring 0 code e
On Wed 27-02-13 12:02:36, Roman Gushchin wrote:
> Hi, all!
>
> I've implemented low limits for memory cgroups. The primary goal was
> to add an ability to protect some memory from reclaiming without using
> mlock(). A kind of "soft mlock()".
Let me restate what I have already mentioned in the pri
There is a long-standing problem in the systemtap community where
accidentally kprobing a delicate function causes the system to crash:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604453
http://sourceware.org/bugzilla/show_bug.cgi?id=2725
https://bugzilla.redhat.com/show_bug.cgi?id=655904
ht
On Wednesday, February 27, 2013 04:56:57 PM Chen Gang wrote:
> 于 2013年02月27日 16:45, Vladimir Kondratiev 写道:
> > On Wednesday, February 27, 2013 02:55:06 PM Chen Gang wrote:
> >>
> >> When make with EXTRA_CFLAGS=-W, it will report error.
> >> so give a check in Makefile.
> >>
> >> Signed-off-by:
On 27/02/13 05:52, Chen Gang wrote:
>
> if call xen_vbd_translate failed, the preq.dev will be not initialized.
> so use blkif->vbd.pdevice instead (still better to print relative info).
preq.dev is initialized a a couple of lines prior to calling
xen_vbd_translate:
preq.dev = req-
>>> On 27.02.13 at 05:52, Chen Gang wrote:
> if call xen_vbd_translate failed, the preq.dev will be not initialized.
> so use blkif->vbd.pdevice instead (still better to print relative info).
>
> Signed-off-by: Chen Gang
Acked-by: Jan Beulich
> ---
> drivers/block/xen-blkback/blkback.c
Hi,
On Wed, Feb 27, 2013 at 7:44 AM, Tzu-Jung Lee wrote:
> I'm wondering is the support for being called in interrupt is on going?
Not that I know of.
> If I'd like to help on this, any suggestion or cautions should be take care
> of?
If you want this to be merged upstream, please describe yo
On Wed, Feb 27, 2013 at 5:52 PM, Paul Mundt wrote:
> On Wed, Feb 27, 2013 at 05:35:51PM +0900, Magnus Damm wrote:
>> On Wed, Feb 27, 2013 at 5:23 PM, Paul Mundt wrote:
>> > So how exactly does this interact with the existing sh_intc code? Or is
>> > there some reason why you have opted to bypass
On Wed, Feb 27, 2013 at 04:36:47PM +0900, Kyungsik Lee wrote:
> Compiler: Linaro ARM gcc 4.6.2
> 2. ARMv7, 1.7GHz based board
>Kernel: linux 3.7
>Uncompressed Kernel Size: 14MB
> Compressed Size Decompression Speed
> LZO 6.0MB34.1MB/sOld
> ---
On Tue, Feb 26, 2013 at 05:40:34PM -0800, Joe Perches wrote:
> On Tue, 2013-02-26 at 22:10 +, Russell King - ARM Linux wrote:
> > So... for a selected kernel version of a particular size, can we please
> > have a comparison between the new LZO code and this LZ4 code, so that
> > we can see whet
>>> On 27.02.13 at 05:52, Chen Gang wrote:
> if call xen_vbd_translate failed, the preq.dev will be not initialized.
> so use blkif->vbd.pdevice instead (still better to print relative info).
You also could have mentioned that even before commit
01c681d4c70d64cb72142a2823f27c4146a02e63 the v
On Tue 26-02-13 16:46:08, David Rientjes wrote:
> On large systems with a lot of memory, walking all RAM to determine page
> types may take a half second or even more.
>
> In non-blockable contexts, the page allocator will emit a page allocation
> failure warning unless __GFP_NOWARN is specified
Daniel,
first of all sorry for the late answer but thanks for testing the driver.
On 2/19/13, Daniel Mack wrote:
> Hi Sebastian,
>
> I did some more tests today and it took me a while to dig for the root
> cause why things were not working for me in the first place - see below.
>
>
> On 09.02.20
于 2013年02月27日 17:46, Vladimir Kondratiev 写道:
> Perhaps, it would be good idea to fight the original problem.
>
if my another 'beautify code' patches are applied into next-* tree.
(that means most of members think it is a good idea).
I will process the original problems (when processing,
>>> On 27.02.13 at 10:50, Roger Pau Monné wrote:
> On 27/02/13 05:52, Chen Gang wrote:
>>
>> if call xen_vbd_translate failed, the preq.dev will be not initialized.
>> so use blkif->vbd.pdevice instead (still better to print relative info).
>
> preq.dev is initialized a a couple of lines prio
On Tue, Feb 26, 2013 at 05:39:46PM -0800, Linus Torvalds wrote:
> On Mon, Feb 25, 2013 at 4:05 PM, Dave Airlie wrote:
> >
> > Highlights:
> >
> > i915: all over the map, haswell power well enhancements, valleyview macro
> > horrors cleaned up, killing lots of legacy GTT
> > code,
>
> Lowlight:
>
> So the new low limit is not a rigid limit. Global reclaim can reclaim
> from a cgroup when its usage is below low_limit_in_bytes although such
> reclaim is less aggressive than when usage is above low_limit_in_bytes.
> Correct?
That's true.
But such reclaim occurs only on very small reclaiming
On Wed, Feb 27, 2013 at 1:08 AM, Greg Kroah-Hartman
wrote:
> 3.4-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Patrik Jakobsson
>
> commit 4f7dfb6788dd022446847fbbfbe45e13bedb5be2 upstream.
>
> The Intel PRM says the M1 and M2 divisors mu
Hi Dmitry,
Thanks for your feedback!
On Wed, Feb 27, 2013 at 7:41 AM, Dmitry Torokhov
wrote:
> Hi Magnus,
>
> On Tue, Feb 26, 2013 at 10:26:23PM +0900, Magnus Damm wrote:
>> From: Magnus Damm
>>
>> Update the Emma Mobile GPIO driver to add DT support.
>>
>
> ...
>
>> @@ -366,15 +387,33 @@ stati
Hi Linus,
Here's the 3.9 pull request for dma-buf framework updates: could you
please pull?
Thanks and best regards,
~Sumit.
The following changes since commit d895cb1af15c04c522a25c79cc429076987c089b:
Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs (2013-0
On 27 February 2013 09:35, ownssh wrote:
> David Howells redhat.com> writes:
>
>>
>>
>> Florian Weimer deneb.enyo.de> wrote:
>>
>> > Seriously, folks, can we go back one step and discuss what problem you
>> > are trying to solve? Is it about allowing third-party kernel modules
>> > in an enviro
On Wed, Feb 27, 2013 at 11:11:38AM +0100, Patrik Jakobsson wrote:
> On Wed, Feb 27, 2013 at 1:08 AM, Greg Kroah-Hartman
> wrote:
> > 3.4-stable review patch. If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Patrik Jakobsson
> >
> > commit 4f7dfb6788dd022
On Wed, Feb 27, 2013 at 09:51:39AM +, Russell King - ARM Linux wrote:
> On Wed, Feb 27, 2013 at 04:36:47PM +0900, Kyungsik Lee wrote:
> > Compiler: Linaro ARM gcc 4.6.2
> > 2. ARMv7, 1.7GHz based board
> >Kernel: linux 3.7
> >Uncompressed Kernel Size: 14MB
> > Compressed Size
On Wed, Feb 27, 2013 at 11:19 AM, Chris Wilson wrote:
> On Wed, Feb 27, 2013 at 11:11:38AM +0100, Patrik Jakobsson wrote:
>> On Wed, Feb 27, 2013 at 1:08 AM, Greg Kroah-Hartman
>> wrote:
>> > 3.4-stable review patch. If anyone has any objections, please let me know.
>> >
>> > --
Am Mittwoch, 27. Februar 2013 schrieb Dave Jones:
> Something I've yet to repeat managed to leak a whole bunch of memory
> while I was travelling, and locked up my workstation.
>
> When I got home, this was the last thing printed out before it locked up
> (it did make it into the logs thankfully)
On Wed, Feb 27, 2013 at 06:52:51PM +0900, Magnus Damm wrote:
> As you know, the INTC code that you are referring to is a full
> interrupt controller designed to work directly with CPU cores like SH
> and ARM. Newer ARM cores like Cortex-A9 all include the GIC both for
> IPI purpose in case of SMP a
于 2013年02月27日 17:57, Jan Beulich 写道:
> You also could have mentioned that even before commit
> 01c681d4c70d64cb72142a2823f27c4146a02e63 the value printed
> here was bogus, as it was the guest provided value from
> req->u.rw.handle rather than the actual device.
pardon ?
I guess what you said
27.02.2013, 13:41, "Michal Hocko" :
> Let me restate what I have already mentioned in the private
> communication.
>
> We already have soft limit which can be implemented to achieve the
> same/similar functionality and in fact this is a long term objective (at
> least for me). I hope I will be able
On Tue, Feb 26, 2013 at 06:16:10AM +, Sethi Varun-B16395 wrote:
> This patch is not present in Joerg's tree and the add_device API in
> the PAMU driver requires this patch.
Will this patch be part of v3.9-rc1?
Joerg
--
To unsubscribe from this list: send the line "unsubscribe linux
>>> On 27.02.13 at 11:38, Chen Gang wrote:
> 于 2013年02月27日 17:57, Jan Beulich 写道:
>> You also could have mentioned that even before commit
>> 01c681d4c70d64cb72142a2823f27c4146a02e63 the value printed
>> here was bogus, as it was the guest provided value from
>> req->u.rw.handle rather than the a
On Tue, 2013-02-26 at 12:58 -0800, Bing Zhao wrote:
> For SD8688, FUNC_INIT command is queued before fw_ready flag is
> set. This causes the following crash as lbs_thread blocks any
> command if fw_ready is not set.
While we're at this; does somebody want to take over Libertas
maintainership? I d
On Wed, Feb 27, 2013 at 11:30:11AM +0530, Santosh Shilimkar wrote:
> P.S: Time and again it proves that making the local timer wakeup
> capable solves the issue.
Slightly different take: it proves that hardware people don't talk to
software people about what they require to make an operating syste
Hi,
On Wed, Feb 06, 2013 at 10:04:24AM +0800, Fengguang Wu wrote:
> Greetings,
>
> I got the below warning and the first bad commit is
can you send a fixup patch ?
--
balbi
signature.asc
Description: Digital signature
On 2013/2/26 21:26, Tejun Heo wrote:
> Hello,
>
> On Tue, Feb 26, 2013 at 2:25 AM, Li Zefan wrote:
>> Sure we can. We'll have to allocate cgrp->name in cgroup_remount() and
>> cgroup_init(), and free cgrp->name in cgroup_kill_sb(). It looks to me
>> the current version is a bit simpler.
>
> Can'
Mike,
On 27-02-2013 01:35, Mike Turquette wrote:
Quoting Eduardo Valentin (2013-02-26 14:53:38)
This patch changes the clock management code to also update
the clock prepare counter, this way we won't skip the enable/disable
operation due to prepare dependencies.
Signed-off-by: Eduardo Valenti
This patch is present in the "next branch" of linux ppc tree maintained by
Kumar Gala.
Following is the commit id:
52c5affc545053d37c0b05224bbf70f5336caa20
I am not sure if this would be part of 3.9-rc1.
Regards
varun
> -Original Message-
> From: Joerg Roedel [mailto:j...@8bytes.org]
>
On Wed, Feb 27, 2013 at 11:46 AM, Dan Williams wrote:
> On Tue, 2013-02-26 at 12:58 -0800, Bing Zhao wrote:
>> For SD8688, FUNC_INIT command is queued before fw_ready flag is
>> set. This causes the following crash as lbs_thread blocks any
>> command if fw_ready is not set.
>
> While we're at this
On Wed, Feb 27, 2013 at 6:26 PM, Dave Airlie wrote:
>>
>> this patch seems to be oopsing on my x86 32-bit machine on bootup, pic
>> attached.
>>
>> .config attached.
>>
>> It looks to me like the weak bit isn't working so well
>>
>> if (platform_sysrq_reset_seq) {
>> for (
Hi Greg,
This patch is specially for 3.0 by integrating upstream commit
cb214ede7657db458fd0b2a25ea0b28dbf900ebc
and ea0dcf903e7d76aa5d483d876215fedcfdfe140f .
I fixed patch format warning and re-send it as v2. Thanks .
---
./scripts/checkpatch.pl x2apic_FADT_check_for_3.0.
On Wed, Feb 27, 2013 at 9:06 PM, Dave Airlie wrote:
> On Wed, Feb 27, 2013 at 6:26 PM, Dave Airlie wrote:
>>>
>>> this patch seems to be oopsing on my x86 32-bit machine on bootup, pic
>>> attached.
>>>
>>> .config attached.
>>>
>>> It looks to me like the weak bit isn't working so well
>>>
>>>
Hi Srivatsa,
I think there is some elegance in Lai's proposal of using a local
trylock for the reader uncontended case and global rwlock to deal with
the contended case without deadlocks. He apparently didn't realize
initially that nested read locks are common, and he seems to have
confused you be
Hi Dave,
> When messages are currently in queue awaiting a response, decrease amount of
> time before attempting cifs_reconnect to SMB_MAX_RTT = 10 seconds. The current
> wait time before attempting to reconnect is currently 2*SMB_ECHO_INTERVAL(120
> seconds) since the last response was recieved.
On Tue, Feb 26, 2013 at 04:30:50PM -0800, Linus Torvalds wrote:
> On Tue, Feb 26, 2013 at 3:43 PM, Linus Torvalds
> wrote:
> >
> > So I'll need to extend on that logic a bit more.
>
> Ok, here's the fleshed-out patch. Also fixed to use "expand_stack()",
> which is what the page fault handling act
On Tue, Feb 26, 2013 at 05:37:17PM -0800, Stephen Boyd wrote:
> On 02/25/13 12:02, Russell King - ARM Linux wrote:
> >
> > This can of worms is getting bigger. We have more problems with our
> > handling of the different VFP versions, specifically the handling of
> > the EX=0 DEX=0 case.
> >
> > V
Am 27.02.2013 11:17, schrieb James Courtier-Dutton:
3) Trust based on date. I trust everything from X that I put on my
system 2 weeks ago, but one week ago X got hacked, so don't trust
anything new from them until the hack has been stopped and the
revokation/correction steps have been completed.
Because we have per cpu timer now, we check if we need to evaluate load again or
not (In case it is recently evaluated). Here the 2nd cpu which got timer
interrupt updates core_dbs_info->sample_type irrespective of load evaluation is
required or not. Which is wrong as the first cpu is dependent on
Following patch has introduced per cpu timers or works for ondemand and
conservative governors.
commit 2abfa876f1117b0ab45f191fb1f82c41b1cbc8fe
Author: Rickard Andersson
Date: Thu Dec 27 14:55:38 2012 +
cpufreq: handle SW coordinated CPUs
This causes ad
The only difference between schedule_delayed_work[_on]() and
queue_delayed_work[_on]() is the workqueue, work is scheduled on. We may need to
modify the delay for works queued with schedule_delayed_work[_on]() calls and
thus adding these helpers.
First users of these new helpers is cpufreq governo
On Mon, Feb 18, 2013 at 06:22:14PM +0530, Varun Sethi wrote:
> Add a new field in the device (powerpc) archdata structure for storing iommu
> domain
> information pointer. This pointer is stored when the device is attached to a
> particular
> domain.
>
>
> Signed-off-by: Varun Sethi
> ---
> -
On Mon, Feb 18, 2013 at 06:22:16PM +0530, Varun Sethi wrote:
> Macros for checking FSL PCI controller version.
>
> Signed-off-by: Varun Sethi
> ---
> arch/powerpc/include/asm/pci-bridge.h |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/p
On Mon, Feb 18, 2013 at 06:22:18PM +0530, Varun Sethi wrote:
> Added the following domain attributes for the FSL PAMU driver:
> 1. Added new iommu stash attribute, which allows setting of the
>LIODN specific stash id parameter through IOMMU API.
> 2. Added an attribute for enabling/disabling DM
It looks to me like the weak bit isn't working so well
if (platform_sysrq_reset_seq) {
for (i = 0; i < ARRAY_SIZE(sysrq_reset_seq); i++) {
key = platform_sysrq_reset_seq[i];
6d: 66 8b 8c 00 00 00 00mov0x0
Hi,
This patch is a second attempt to add basic support of OMAP4 Blaze Tablet
software development platform - in this case using only Device Tree.
Additional information about this platform can be found here:
http://www.svtronics.com/omap?product_id=15
Ruslan Bilovol (1):
ARM: DTS: OMAP4: Add
The OMAP4 Blaze Tablet is TI OMAP4 processor-based
development platform in a tablet formfactor.
The platform contains many of the features found in
present-day handsets (such as audio, video, wireless
functions and user interfaces) and in addition
contains features for software development and test
On 27 February 2013 11:27, Alexander Holler wrote:
> Am 27.02.2013 11:17, schrieb James Courtier-Dutton:
>
>
>> 3) Trust based on date. I trust everything from X that I put on my
>> system 2 weeks ago, but one week ago X got hacked, so don't trust
>> anything new from them until the hack has been
On Tue, Feb 26, 2013 at 8:54 AM, richard -rw- weinberger
wrote:
> On Tue, Feb 26, 2013 at 7:31 AM, Srinivas Eeda
> wrote:
>> This is due to a race in lock mastery/purge. I have recently fixed this
>> problem but haven't yet submitted the patch to mainline. Please file a
>> Service request with O
> -Original Message-
> From: Stuart Yoder [mailto:b08...@gmail.com]
> Sent: Wednesday, February 27, 2013 4:03 AM
> To: Sethi Varun-B16395
> Cc: io...@lists.linux-foundation.org; linuxppc-...@lists.ozlabs.org;
> linux-kernel@vger.kernel.org; Wood Scott-B07421; Joerg Roedel; Yoder
> Stuart-
On Wed, Feb 27, 2013 at 12:52 PM, richard -rw- weinberger
wrote:
> On Tue, Feb 26, 2013 at 8:54 AM, richard -rw- weinberger
> wrote:
>> On Tue, Feb 26, 2013 at 7:31 AM, Srinivas Eeda
>> wrote:
>>> This is due to a race in lock mastery/purge. I have recently fixed this
>>> problem but haven't ye
Hi Sedat,
> I have reported this issue several times (first for next-20130223) to
> LKML and Linux-Next MLs but got no answer.
> I am unsure which is the root cause for all this trouble.
>
> Can someone have a look at this, please?
>
> [0.065787] smpboot: CPU0: Intel(R) Core(TM) i5-2467M CPU
Hi Sedat,
> while digging into a Linux-Next issue [0] I wanted to browse the
> watchdog GitWeb, but it seems not to be available for me!
Correct. I disabled it because the server has not enough memory...
Kind regards,
Wim.
--
To unsubscribe from this list: send the line "unsubscribe linux-kerne
From: Freddy Xin
This is a resubmission.
Fixed endianness issue on big endian systems and verified this driver on iBook
G4.
Removed steps that change net->features in ax88179_set_features function.
Added "const" to ethtool_ops structure and fixed the coding style of
AX88179_BULKIN_SIZE array.
F
Hi Kumar,Ben,
I am implementing the Freescale PAMU (IOMMU) driver using the Linux IOMMU API.
In this particular patch, I have added a new field to dev_archdata structure to
store the dma domain information.
This field is updated whenever we attach a device to an iommu domain.
Regards
Varun
> --
On Wed, Feb 27, 2013 at 12:58 PM, Wim Van Sebroeck wrote:
> Hi Sedat,
>
>> while digging into a Linux-Next issue [0] I wanted to browse the
>> watchdog GitWeb, but it seems not to be available for me!
>
> Correct. I disabled it because the server has not enough memory...
>
Then please update your
On 27 February 2013 16:59, Viresh Kumar wrote:
> The only difference between schedule_delayed_work[_on]() and
> queue_delayed_work[_on]() is the workqueue, work is scheduled on. We may need
> to
> modify the delay for works queued with schedule_delayed_work[_on]() calls and
> thus adding these he
On 21/02/13 03:33, Linux Kernel Mailing List wrote:
> Gitweb:
> http://git.kernel.org/linus/;a=commit;h=4a5fc6d7074de72dd836fbb9c5cd79f9a491871c
> Commit: 4a5fc6d7074de72dd836fbb9c5cd79f9a491871c
> Parent: 92941382e8b80c55a4ad06b88a3bf95110969693
> Author: Chun-Yeow Yeoh
> AuthorD
Hi, Linus,
Please pull from the git repository at
git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git release
to receive thermal management updates for v3.9 with top-most commit
f5b6d45f8cf688f51140fd21f1da3b90562762a9
thermal: rcar: remove __devinitconst (2013-02-22 17:38:40 +080
On Wed, Feb 27, 2013 at 11:21 AM, Kasatkin, Dmitry
wrote:
> On Wed, Feb 27, 2013 at 1:22 AM, Mimi Zohar wrote:
>> On Tue, 2013-02-26 at 20:34 +, Al Viro wrote:
>>> On Tue, Feb 26, 2013 at 02:32:08PM -0500, Mimi Zohar wrote:
>>> > Before anything gets access to the file, the file needs to be m
* Roberto Vitillo wrote:
> The proposed patch adds the convert tool to perf which allows to convert a
> perf.data file to a callgrind data file which can subsequently be displayed
> with
> kcachegrind. Callgraphs are not supported.
Would be nice to add a usecase description to the documentat
On Tue, Feb 26, 2013 at 11:06 PM, Peter Jones wrote:
> On Tue, Feb 26, 2013 at 10:57:38PM +0100, Geert Uytterhoeven wrote:
>
>> BTW, I assume UEFI checks itself if enrolled hashes have been revoked,
>> so it must phone home to some server? That must be disabled as well.
>
> No. Quit fearmongering
On Tue, Feb 12, 2013 at 12:15 AM, Josh Boyer wrote:
> Using /dev/pstore as a mount point for the pstore filesystem is slightly
> awkward. We don't normally mount filesystems in /dev/ and the /dev/pstore
> file isn't created automatically by anything. While this method will
> still work, we can c
On 02/27/2013 12:11 AM, Yinghai Lu wrote:
> On Tue, Feb 26, 2013 at 8:43 PM, Yasuaki Ishimatsu
> wrote:
>> 2013/02/27 13:04, Yinghai Lu wrote:
>>>
>>> On Tue, Feb 26, 2013 at 7:38 PM, Yasuaki Ishimatsu
>>> wrote:
2013/02/27 11:30, Yinghai Lu wrote:
>
> Do you mean you can not bo
On Wed, Feb 27, 2013 at 01:32:30PM +0100, Geert Uytterhoeven wrote:
> So revocation will only be done by the guest OS?
> I.e. if I only boot my own trusted Linux, even if it's signed with the MS key,
> the MS key _on my system_ will never be revoked?
As long as you never apply any updates that wi
On 2013.02.26 at 15:39 -0500, Theodore Ts'o wrote:
>
> The following changes since commit 9931faca02c604c22335f5a935a501bb2ace6e20:
>
> Linux 3.8-rc3 (2013-01-09 18:59:55 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git
> t
2013/2/26 Jiri Olsa :
> If we allocate perf ring buffer with the size of single page,
> we will get memory corruption when releasing it. It's caused
> by rb_free_work function (the CONFIG_PERF_USE_VMALLOC option
> variant).
>
> For single page sized ring buffer the page_order is -1 (because
> nr_pa
On 2013.02.21 at 18:19 +, Namhyung Kim wrote:
> Markus Trippelsdorf trippelsdorf.de> writes:
> >
> > perf top doesn't unlink /tmp/perf-vdso.so.* on exit.
> > Fix this by calling vdso__exit() before exit(0).
>
> > @@ -602,6 +603,7 @@ static void *display_thread_tui(void *arg)
> >
- Original Message -
> Milos Vyletel writes:
> > On Feb 25, 2013, at 5:12 PM, Greg KH wrote:
> >
> >> On Fri, Feb 22, 2013 at 10:14:49AM +1030, Rusty Russell wrote:
> >>> Milos Vyletel writes:
> >>>
> When virtio-blk device is resized from host (using block_resize from
> QEMU)
The Palmas familly of chips has LED support. This is not always muxed
to output pins so depending on the setting of the mux this driver
will create the appropriate LED class devices.
Signed-off-by: Graeme Gregory
Signed-off-by: Ian Lartey
---
drivers/leds/leds-palmas.c | 574 ++
Add the Kconfig and Makefile for the Palmas LED driver.
Signed-off-by: Graeme Gregory
Signed-off-by: Ian Lartey
---
drivers/leds/Kconfig |9 +
drivers/leds/Makefile |1 +
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
On Wed, Feb 27, 2013 at 02:02:39PM +0100, Frederic Weisbecker wrote:
> 2013/2/26 Jiri Olsa :
> > If we allocate perf ring buffer with the size of single page,
> > we will get memory corruption when releasing it. It's caused
> > by rb_free_work function (the CONFIG_PERF_USE_VMALLOC option
> > varian
Hi Linus,
please pull these kbuild changes for v3.9-rc1:
* Alias generation in modpost is cross-compile safe.
* kernel/timeconst.h is now generated using a bc script instead of perl.
* scripts/link-vmlinux.sh now works with an alternative $KCONFIG_CONFIG.
* destination-y for exported headers is s
On Wed, Feb 27, 2013 at 2:49 AM, Li Zefan wrote:
> Well, cgrp->name is a pointer to struct cgroup_name.
>
> At first I tried to declare cgrp->name as char *, and use container_of()
> to get struct cgroup_name, but it didn't result in simpler code.
Hmmm? But then what prevents defining const stru
1 - 100 of 536 matches
Mail list logo
