On Mon, Dec 23, 2024 at 11:27 PM Mukesh Ojha
wrote:
>
> Hi All,
>
> Wanted to check if we have encountered remoteproc use case where a device
> with dma is assigned to a remoteproc with its own streamid and iommu
> translation context. This DMA device can have a selective DMA range
> within the r
Hi Jisheng,
On 6/16/2020 1:03 PM, Jisheng Zhang wrote:
> Hi,
>
> After reading current dwc2 code, I got an impression that resume from suspend
> to ram isn't supported for DWC2_POWER_DOWN_PARAM_NONE case, right? In fact
'ram' Do you mean on suspend save registers in RAM?
If yes, then in case when
Hi Marc,
Thanks a lot for your comments. I will work on exploring how SDEI can be
used for it.
Thanks
Neeraj
On 5/8/2020 9:41 PM, Marc Zyngier wrote:
On Fri, 08 May 2020 14:34:10 +0100,
Neeraj Upadhyay wrote:
Hi Marc,
On 5/8/2020 6:23 PM, Marc Zyngier wrote:
On Fri, 8 May 2020 18:09:0
On Fri, 08 May 2020 14:34:10 +0100,
Neeraj Upadhyay wrote:
>
> Hi Marc,
>
> On 5/8/2020 6:23 PM, Marc Zyngier wrote:
> > On Fri, 8 May 2020 18:09:00 +0530
> > Neeraj Upadhyay wrote:
> >
> >> Hi Marc,
> >>
> >> On 5/8/2020 5:57 PM, Marc Zyngier wrote:
> >>> On Fri, 8 May 2020 16:36:42 +0530
>
Hi Marc,
On 5/8/2020 6:23 PM, Marc Zyngier wrote:
On Fri, 8 May 2020 18:09:00 +0530
Neeraj Upadhyay wrote:
Hi Marc,
On 5/8/2020 5:57 PM, Marc Zyngier wrote:
On Fri, 8 May 2020 16:36:42 +0530
Neeraj Upadhyay wrote:
Hi Marc,
On 5/8/2020 4:15 PM, Marc Zyngier wrote:
On Thu, 07 May 2020
Hi Marc,
On 5/8/2020 5:57 PM, Marc Zyngier wrote:
On Fri, 8 May 2020 16:36:42 +0530
Neeraj Upadhyay wrote:
Hi Marc,
On 5/8/2020 4:15 PM, Marc Zyngier wrote:
On Thu, 07 May 2020 17:06:19 +0100,
Neeraj Upadhyay wrote:
Hi,
I have one query regarding pseudo NMI support on GIC v3; from what
On Fri, 8 May 2020 18:09:00 +0530
Neeraj Upadhyay wrote:
> Hi Marc,
>
> On 5/8/2020 5:57 PM, Marc Zyngier wrote:
> > On Fri, 8 May 2020 16:36:42 +0530
> > Neeraj Upadhyay wrote:
> >
> >> Hi Marc,
> >>
> >> On 5/8/2020 4:15 PM, Marc Zyngier wrote:
> >>> On Thu, 07 May 2020 17:06:19 +0100,
>
On Fri, 8 May 2020 16:36:42 +0530
Neeraj Upadhyay wrote:
> Hi Marc,
>
> On 5/8/2020 4:15 PM, Marc Zyngier wrote:
> > On Thu, 07 May 2020 17:06:19 +0100,
> > Neeraj Upadhyay wrote:
> >>
> >> Hi,
> >>
> >> I have one query regarding pseudo NMI support on GIC v3; from what I
> >> could understan
Hi Marc,
On 5/8/2020 4:15 PM, Marc Zyngier wrote:
On Thu, 07 May 2020 17:06:19 +0100,
Neeraj Upadhyay wrote:
Hi,
I have one query regarding pseudo NMI support on GIC v3; from what I
could understand, GIC v3 supports pseudo NMI setup for SPIs and PPIs.
However the request_nmi() in irq framewo
On Thu, 07 May 2020 17:06:19 +0100,
Neeraj Upadhyay wrote:
>
> Hi,
>
> I have one query regarding pseudo NMI support on GIC v3; from what I
> could understand, GIC v3 supports pseudo NMI setup for SPIs and PPIs.
> However the request_nmi() in irq framework requires NMI to be per cpu
> interrupt
On 8/28/19 1:02 PM, Srinivas Neeli wrote:
> Case 1:
> can_put_echo_skb(); -> skb = can_create_echo_skb(skb); -> return skb;
>
> In can_create_echo_skb() not using the shared_skb, so we are returning the
> old skb.
> Storing the return value in "skb". But it's a pointer, for storing that need
> d
d a patch.
Thanks
Srinivas Neeli
> -Original Message-
> From: Marc Kleine-Budde
> Sent: Wednesday, August 28, 2019 1:03 AM
> To: Srinivas Neeli ; w...@grandegger.com
> Cc: Srinivas Goud ; Naga Sureshkumar Relli
> ; Appana Durga Kedareswara Rao
> ; linux-...@vger.kernel.o
On 29.03.19 05:35, Ajay Garg wrote:
> I am wanting to have some insight on how a modem plugs into the
> linux-kernel at architecture level.
Well, that depends ... which type of modem ? which protocols ?
The most common case are the classical serial modems, attached to
some uart (including those
On Mon, Oct 01, 2018 at 09:30:35AM +, Kalyani Akula wrote:
> This email and any attachments are intended for the sole use of the named
> recipient(s) and contain(s) confidential information that may be proprietary,
> privileged or copyrighted under applicable law. If you are not the intended
On Thu, Aug 23, 2018 at 08:20:36PM +0530, Kedareswararao Appana wrote:
> On arm64 platform I have booted Linux only with > 32-bit
> Address i.e from 0x8 (reg = <0x8 0x 0x0 0x8000>)
So you have 2GB of RAM starting at 0x8__.
> In my driver, I am using dma_
On Tue, 21 Aug 2018, Mukesh Ojha wrote:
> On 8/21/2018 7:27 PM, Thomas Gleixner wrote:
> > > If it is specifically was dependent on notifiers, did we missed to remove
> > > it as the notifiers are gone or the usecase still there?
> > As the comment says
>
> Thanks for your reply
> Sorry, for f
On 8/21/2018 7:27 PM, Thomas Gleixner wrote:
On Tue, 21 Aug 2018, Mukesh Ojha wrote:
Hi All,
This is about one of field in struct cpuhp_step
* @skip_onerr: Do not invoke the functions on error rollback
* Will go away once the notifiers are gone
bool
On Tue, 21 Aug 2018, Mukesh Ojha wrote:
> Hi All,
>
> This is about one of field in struct cpuhp_step
>
> * @skip_onerr: Do not invoke the functions on error rollback
> * Will go away once the notifiers are gone
> bool skip_onerr;
>
> Why this field was i
On 8/17/2018 6:28 PM, Al Viro wrote:
On Fri, Aug 17, 2018 at 03:39:22PM +0530, Mukesh Ojha wrote:
Hi Al Viro,
Is there is reason we have kept data->found++, if the dentry already there
in shrink list ?
static enum d_walk_ret select_collect(
...
if (dentry->d_flags & DCACHE_SHRINK_L
On Fri, Aug 17, 2018 at 03:39:22PM +0530, Mukesh Ojha wrote:
> Hi Al Viro,
>
> Is there is reason we have kept data->found++, if the dentry already there
> in shrink list ?
>
> static enum d_walk_ret select_collect(
> ...
> if (dentry->d_flags & DCACHE_SHRINK_LIST) {
> dat
On Mon, Aug 09, 2010 at 11:02:44AM +0100, David Woodhouse wrote:
> If my corporate overloads told me I had to use my Exchange "messaging"
> account for external email communication, they would get a quite clear
> 'no' in response. My response may also contain suggestions that they use
> certain oth
On 02/02/2018 06:49 PM, Rafael J. Wysocki wrote:
> On Fri, Feb 2, 2018 at 1:53 PM, Prateek Sood wrote:
>> On 02/02/2018 05:18 PM, Rafael J. Wysocki wrote:
>>> On Friday, February 2, 2018 12:41:58 PM CET Prateek Sood wrote:
Hi Viresh,
One scenario is there where a kernel panic is obs
On Fri, Feb 2, 2018 at 1:53 PM, Prateek Sood wrote:
> On 02/02/2018 05:18 PM, Rafael J. Wysocki wrote:
>> On Friday, February 2, 2018 12:41:58 PM CET Prateek Sood wrote:
>>> Hi Viresh,
>>>
>>> One scenario is there where a kernel panic is observed in
>>> cpufreq during suspend/resume.
>>>
>>> pm_s
On 02/02/2018 05:18 PM, Rafael J. Wysocki wrote:
> On Friday, February 2, 2018 12:41:58 PM CET Prateek Sood wrote:
>> Hi Viresh,
>>
>> One scenario is there where a kernel panic is observed in
>> cpufreq during suspend/resume.
>>
>> pm_suspend()
>> suspend_devices_and_enter()
>> dpm_suspend_s
On Friday, February 2, 2018 12:41:58 PM CET Prateek Sood wrote:
> Hi Viresh,
>
> One scenario is there where a kernel panic is observed in
> cpufreq during suspend/resume.
>
> pm_suspend()
> suspend_devices_and_enter()
> dpm_suspend_start()
> dpm_prepare()
>
> Failure in dpm_prepare
On 1/16/2018 12:50 PM, Alexey Dobriyan wrote:
On Tue, Jan 16, 2018 at 11:06:47AM +0530, Kohli, Gaurav wrote:
On 1/10/2018 10:50 AM, Alexey Dobriyan wrote:
We are seeing crash in do_task_stat while accessing stack pointer, It
seems same task has already completed do_exit call.
So it seems a ra
On Tue, Jan 16, 2018 at 11:06:47AM +0530, Kohli, Gaurav wrote:
> On 1/10/2018 10:50 AM, Alexey Dobriyan wrote:
>
> >> We are seeing crash in do_task_stat while accessing stack pointer, It
> >> seems same task has already completed do_exit call.
> >> So it seems a race between them:
> > Please, pos
On 1/10/2018 10:50 AM, Alexey Dobriyan wrote:
We are seeing crash in do_task_stat while accessing stack pointer, It
seems same task has already completed do_exit call.
So it seems a race between them:
Please, post exact kernel version and struct task_struct::usage if you
still have that kernel
On 1/15/2018 4:32 PM, John Ogness wrote:
Hello Gaurav.
On 2018-01-09, Kohli, Gaurav wrote:
We are seeing crash in do_task_stat while accessing stack pointer, It
seems same task has already completed do_exit call.
So it seems a race between them:
Below is the crash trace:
49750.534377] Kernel
Hello Gaurav.
On 2018-01-09, Kohli, Gaurav wrote:
> We are seeing crash in do_task_stat while accessing stack pointer, It
> seems same task has already completed do_exit call.
> So it seems a race between them:
>
> Below is the crash trace:
> 49750.534377] Kernel BUG at ff8e7a4c53a8 [verbose
Hi John, Ingo
As still we are seeing race between do_task_stat and do_exit of task,
Can't we have to
put more strict check in case, if stack pointer is NULL in below code :
if (permitted && (task->flags & PF_DUMPCORE)) {
eip = KSTK_EIP(task);
> We are seeing crash in do_task_stat while accessing stack pointer, It
> seems same task has already completed do_exit call.
> So it seems a race between them:
Please, post exact kernel version and struct task_struct::usage if you
still have that kernel core (or even full task_struct)
On Tue, Dec 26, 2017 at 05:58:55PM +0530, Kohli, Gaurav wrote:
> Hi ,
> We have seen lot of crashes in 4.9 during boot in n_tty_receive_buf_common,
> when tty->disc_data
> becomes NULL, Below is the call stack for same
> 29.710969] PC is at n_tty_receive_buf_common+0x68/0xa3c
> [ 29.716425] LR is
On Sat, Oct 28, 2017 at 09:19:52AM +0530, Neeraj Upadhyay wrote:
> On 10/28/2017 03:50 AM, Paul E. McKenney wrote:
> >On Fri, Oct 27, 2017 at 10:15:04PM +0530, Neeraj Upadhyay wrote:
> >>On 10/27/2017 05:56 PM, Paul E. McKenney wrote:
> >>>On Fri, Oct 27, 2017 at 02:23:07PM +0530, Neeraj Upadhyay w
On 10/28/2017 03:50 AM, Paul E. McKenney wrote:
On Fri, Oct 27, 2017 at 10:15:04PM +0530, Neeraj Upadhyay wrote:
On 10/27/2017 05:56 PM, Paul E. McKenney wrote:
On Fri, Oct 27, 2017 at 02:23:07PM +0530, Neeraj Upadhyay wrote:
Hi,
One query regarding srcu_funnel_exp_start() function in
kernel/
On Fri, Oct 27, 2017 at 10:15:04PM +0530, Neeraj Upadhyay wrote:
> On 10/27/2017 05:56 PM, Paul E. McKenney wrote:
> >On Fri, Oct 27, 2017 at 02:23:07PM +0530, Neeraj Upadhyay wrote:
> >>Hi,
> >>
> >>One query regarding srcu_funnel_exp_start() function in
> >>kernel/rcu/srcutree.c.
> >>
> >>static
On 10/27/2017 05:56 PM, Paul E. McKenney wrote:
On Fri, Oct 27, 2017 at 02:23:07PM +0530, Neeraj Upadhyay wrote:
Hi,
One query regarding srcu_funnel_exp_start() function in
kernel/rcu/srcutree.c.
static void srcu_funnel_exp_start(struct srcu_struct *sp, struct
srcu_node *snp,
On Fri, Oct 27, 2017 at 02:23:07PM +0530, Neeraj Upadhyay wrote:
> Hi,
>
> One query regarding srcu_funnel_exp_start() function in
> kernel/rcu/srcutree.c.
>
> static void srcu_funnel_exp_start(struct srcu_struct *sp, struct
> srcu_node *snp,
> unsigned long s)
> {
On Thu, 26 Oct 2017, Neeraj Upadhyay wrote:
> Hi tglx,
>
> Forgot to mention, we are using kernel stable version 3.18
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/kernel/time/timekeeping.c?h=v3.18.77
>
> wall time is being set to a value close to epoch
> but les
Hi tglx,
Forgot to mention, we are using kernel stable version 3.18
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/kernel/time/timekeeping.c?h=v3.18.77
wall time is being set to a value close to epoch
but less than epoch + current uptime.
Looks like
https://git.ke
On Thu, 26 Oct 2017, Neeraj Upadhyay wrote:
> We have one query regarding the __hrtimer_get_next_event().
> The expires_next.tv64 is set to 0 if it is < 0. We observed
> an hrtimer interrupt storm for one of the hrtimers with
> below properties:
>
> * Expires for the hrtimer was set to KTIME_MAX.
On Thu, Sep 21, 2017 at 06:30:12PM +0200, Peter Zijlstra wrote:
> On Thu, Sep 21, 2017 at 09:00:48AM -0700, Paul E. McKenney wrote:
> > commit c21c9b78182e35eb0e72ef4e3bba3054f26eaaea
[ . . . ]
> Inconsistent spacing after your bullet 'o', first two points have a
> space the last two a tab or so.
On Thu, Sep 21, 2017 at 09:00:48AM -0700, Paul E. McKenney wrote:
> commit c21c9b78182e35eb0e72ef4e3bba3054f26eaaea
> Author: Paul E. McKenney
> Date: Mon Sep 18 08:54:40 2017 -0700
>
> sched: Make resched_cpu() unconditional
>
> The current implementation of synchronize_sched_expe
On Thu, Sep 21, 2017 at 08:31:34AM -0700, Paul E. McKenney wrote:
> > And given RCU is the only user of that thing, I suppose we can indeed
> > change it to a full lock.
>
> Thank you! May I have your ack?
Last version I saw still had a Changelog that looked like whitespace
damage.
On Thu, Sep 21, 2017 at 03:59:46PM +0200, Peter Zijlstra wrote:
> On Tue, Sep 19, 2017 at 08:31:26AM -0700, Paul E. McKenney wrote:
> > So I have this one queued. Objections?
>
> Changelog reads like its whitespace damaged.
It does, now that you mention it. How about the updated version below?
On Thu, 21 Sep 2017 15:55:46 +0200
Peter Zijlstra wrote:
> On Mon, Sep 18, 2017 at 11:11:05AM -0400, Steven Rostedt wrote:
> > On Sun, 17 Sep 2017 11:37:06 +0530
> > Neeraj Upadhyay wrote:
> >
> > > Hi Paul, how about replacing raw_spin_trylock_irqsave with
> > > raw_spin_lock_irqsave in resc
On Thu, Sep 21, 2017 at 03:57:49PM +0200, Peter Zijlstra wrote:
> On Mon, Sep 18, 2017 at 09:55:27AM -0700, Paul E. McKenney wrote:
> > On Mon, Sep 18, 2017 at 12:29:31PM -0400, Steven Rostedt wrote:
> > > On Mon, 18 Sep 2017 09:24:12 -0700
> > > "Paul E. McKenney" wrote:
> > >
> > >
> > > > As
On Thu, Sep 21, 2017 at 03:55:46PM +0200, Peter Zijlstra wrote:
> On Mon, Sep 18, 2017 at 11:11:05AM -0400, Steven Rostedt wrote:
> > On Sun, 17 Sep 2017 11:37:06 +0530
> > Neeraj Upadhyay wrote:
> >
> > > Hi Paul, how about replacing raw_spin_trylock_irqsave with
> > > raw_spin_lock_irqsave in r
On Tue, Sep 19, 2017 at 08:31:26AM -0700, Paul E. McKenney wrote:
> So I have this one queued. Objections?
Changelog reads like its whitespace damaged.
> commit bc43e2e7e08134e6f403ac845edcf4f85668d803
> Author: Paul E. McKenney
> Date: Mon Sep 18 08:54:40 2017 -0700
>
> sched: Make resc
On Mon, Sep 18, 2017 at 09:55:27AM -0700, Paul E. McKenney wrote:
> On Mon, Sep 18, 2017 at 12:29:31PM -0400, Steven Rostedt wrote:
> > On Mon, 18 Sep 2017 09:24:12 -0700
> > "Paul E. McKenney" wrote:
> >
> >
> > > As soon as I work through the backlog of lockdep complaints that
> > > appeared i
On Mon, Sep 18, 2017 at 11:11:05AM -0400, Steven Rostedt wrote:
> On Sun, 17 Sep 2017 11:37:06 +0530
> Neeraj Upadhyay wrote:
>
> > Hi Paul, how about replacing raw_spin_trylock_irqsave with
> > raw_spin_lock_irqsave in resched_cpu()? Are there any paths
> > in RCU code, which depend on trylock c
On Tue, Sep 19, 2017 at 11:58:59AM -0400, Steven Rostedt wrote:
> On Tue, 19 Sep 2017 08:31:26 -0700
> "Paul E. McKenney" wrote:
>
> > commit bc43e2e7e08134e6f403ac845edcf4f85668d803
> > Author: Paul E. McKenney
> > Date: Mon Sep 18 08:54:40 2017 -0700
> >
> > sched: Make resched_cpu() un
On Tue, 19 Sep 2017 08:31:26 -0700
"Paul E. McKenney" wrote:
> commit bc43e2e7e08134e6f403ac845edcf4f85668d803
> Author: Paul E. McKenney
> Date: Mon Sep 18 08:54:40 2017 -0700
>
> sched: Make resched_cpu() unconditional
>
> The current implementation of synchronize_sched_expedit
On Mon, Sep 18, 2017 at 09:24:12AM -0700, Paul E. McKenney wrote:
> On Mon, Sep 18, 2017 at 12:12:13PM -0400, Steven Rostedt wrote:
> > On Mon, 18 Sep 2017 09:01:25 -0700
> > "Paul E. McKenney" wrote:
> >
> >
> > > sched: Make resched_cpu() unconditional
> > >
> > > The current impl
On Tue, Sep 19, 2017 at 08:11:53AM +0200, Mike Galbraith wrote:
> On Tue, 2017-09-19 at 13:37 +0800, Boqun Feng wrote:
> > On Mon, Sep 18, 2017 at 09:04:56PM -0700, Paul E. McKenney wrote:
> > > On Tue, Sep 19, 2017 at 11:48:22AM +0900, Byungchul Park wrote:
> > > > On Mon, Sep 18, 2017 at 07:33:29
On Tue, Sep 19, 2017 at 08:11:53AM +0200, Mike Galbraith wrote:
> https://lkml.org/lkml/2017/9/5/184
Now, I checked the patches above. It looks to be a good approach to me.
Thanks,
Byungchul
> Peter's patches worked for me, but per tglx, additional (non-
> grasshopper level) hotplug-fu is requir
On Tue, 2017-09-19 at 13:37 +0800, Boqun Feng wrote:
> On Mon, Sep 18, 2017 at 09:04:56PM -0700, Paul E. McKenney wrote:
> > On Tue, Sep 19, 2017 at 11:48:22AM +0900, Byungchul Park wrote:
> > > On Mon, Sep 18, 2017 at 07:33:29PM -0700, Paul E. McKenney wrote:
> > > > > > Hello Paul and Steven,
> >
On Mon, Sep 18, 2017 at 09:04:56PM -0700, Paul E. McKenney wrote:
> On Tue, Sep 19, 2017 at 11:48:22AM +0900, Byungchul Park wrote:
> > On Mon, Sep 18, 2017 at 07:33:29PM -0700, Paul E. McKenney wrote:
> > > > > Hello Paul and Steven,
> > > > >
So I think this is another false positive, and the r
On Tue, Sep 19, 2017 at 11:48:22AM +0900, Byungchul Park wrote:
> On Mon, Sep 18, 2017 at 07:33:29PM -0700, Paul E. McKenney wrote:
> > > > Hello Paul and Steven,
> > > >
> > > > This is saying:
> > > >
> > > > Thread A
> > > >
> > > > takedown_cpu()
> > > >irq_lock_sparse()
> > > >
On Mon, Sep 18, 2017 at 07:33:29PM -0700, Paul E. McKenney wrote:
> > > Hello Paul and Steven,
> > >
> > > This is saying:
> > >
> > > Thread A
> > >
> > > takedown_cpu()
> > >irq_lock_sparse()
> > >wait_for_completion(&st->done) // Wait for completion of B
> > >irq_unlock_sp
On Tue, Sep 19, 2017 at 11:06:10AM +0900, Byungchul Park wrote:
> On Tue, Sep 19, 2017 at 10:50:27AM +0900, Byungchul Park wrote:
> > On Mon, Sep 18, 2017 at 04:53:11PM -0700, Paul E. McKenney wrote:
> > > So, Byungchul, any enlightenment? Please see lockdep splat below.
> > >
> > >
On Mon, Sep 18, 2017 at 09:23:01PM -0400, Steven Rostedt wrote:
> On Mon, 18 Sep 2017 16:53:11 -0700
> "Paul E. McKenney" wrote:
>
> > On Mon, Sep 18, 2017 at 09:55:27AM -0700, Paul E. McKenney wrote:
> > > On Mon, Sep 18, 2017 at 12:29:31PM -0400, Steven Rostedt wrote:
> > > > On Mon, 18 Sep 2
On Tue, Sep 19, 2017 at 10:50:27AM +0900, Byungchul Park wrote:
> On Mon, Sep 18, 2017 at 04:53:11PM -0700, Paul E. McKenney wrote:
> > So, Byungchul, any enlightenment? Please see lockdep splat below.
> >
> > Thanx, Paul
> >
> > --
On Mon, Sep 18, 2017 at 12:29:31PM -0400, Steven Rostedt wrote:
> On Mon, 18 Sep 2017 09:24:12 -0700
> "Paul E. McKenney" wrote:
>
>
> > As soon as I work through the backlog of lockdep complaints that
> > appeared in the last merge window... :-(
> >
> > sparse_irq_lock, I am looking at you!!!
On Mon, Sep 18, 2017 at 04:53:11PM -0700, Paul E. McKenney wrote:
> So, Byungchul, any enlightenment? Please see lockdep splat below.
>
> Thanx, Paul
>
>
>
> [ 35.310
On Mon, 18 Sep 2017 16:53:11 -0700
"Paul E. McKenney" wrote:
> On Mon, Sep 18, 2017 at 09:55:27AM -0700, Paul E. McKenney wrote:
> > On Mon, Sep 18, 2017 at 12:29:31PM -0400, Steven Rostedt wrote:
> > > On Mon, 18 Sep 2017 09:24:12 -0700
> > > "Paul E. McKenney" wrote:
> > >
> > >
> > > >
On Mon, Sep 18, 2017 at 09:55:27AM -0700, Paul E. McKenney wrote:
> On Mon, Sep 18, 2017 at 12:29:31PM -0400, Steven Rostedt wrote:
> > On Mon, 18 Sep 2017 09:24:12 -0700
> > "Paul E. McKenney" wrote:
> >
> >
> > > As soon as I work through the backlog of lockdep complaints that
> > > appeared i
On Mon, Sep 18, 2017 at 12:29:31PM -0400, Steven Rostedt wrote:
> On Mon, 18 Sep 2017 09:24:12 -0700
> "Paul E. McKenney" wrote:
>
>
> > As soon as I work through the backlog of lockdep complaints that
> > appeared in the last merge window... :-(
> >
> > sparse_irq_lock, I am looking at you!!!
On Mon, 18 Sep 2017 09:24:12 -0700
"Paul E. McKenney" wrote:
> As soon as I work through the backlog of lockdep complaints that
> appeared in the last merge window... :-(
>
> sparse_irq_lock, I am looking at you!!! ;-)
I just hit one too, and decided to write a patch to show a chain of 3
whe
On Mon, Sep 18, 2017 at 12:12:13PM -0400, Steven Rostedt wrote:
> On Mon, 18 Sep 2017 09:01:25 -0700
> "Paul E. McKenney" wrote:
>
>
> > sched: Make resched_cpu() unconditional
> >
> > The current implementation of synchronize_sched_expedited() incorrectly
> > assumes that resch
On Mon, 18 Sep 2017 09:01:25 -0700
"Paul E. McKenney" wrote:
> sched: Make resched_cpu() unconditional
>
> The current implementation of synchronize_sched_expedited() incorrectly
> assumes that resched_cpu() is unconditional, which it is not. This means
> that synchronize_s
On Mon, Sep 18, 2017 at 11:11:05AM -0400, Steven Rostedt wrote:
> On Sun, 17 Sep 2017 11:37:06 +0530
> Neeraj Upadhyay wrote:
>
> > Hi Paul, how about replacing raw_spin_trylock_irqsave with
> > raw_spin_lock_irqsave in resched_cpu()? Are there any paths
> > in RCU code, which depend on trylock c
On Sun, 17 Sep 2017 11:37:06 +0530
Neeraj Upadhyay wrote:
> Hi Paul, how about replacing raw_spin_trylock_irqsave with
> raw_spin_lock_irqsave in resched_cpu()? Are there any paths
> in RCU code, which depend on trylock check/spinlock recursion?
It looks to me that resched_cpu() was added for no
On 09/17/2017 06:30 AM, Paul E. McKenney wrote:
On Fri, Sep 15, 2017 at 04:44:38PM +0530, Neeraj Upadhyay wrote:
Hi,
We have one query regarding the behavior of RCU expedited grace period,
for scenario where resched_cpu() in sync_sched_exp_handler() fails to
acquire the rq lock and returns w/
On Fri, Sep 15, 2017 at 04:44:38PM +0530, Neeraj Upadhyay wrote:
> Hi,
>
> We have one query regarding the behavior of RCU expedited grace period,
> for scenario where resched_cpu() in sync_sched_exp_handler() fails to
> acquire the rq lock and returns w/o setting the need_resched. In this
> case,
On Wed, 2 Aug 2017 12:02:21 +0530
Pratyush Anand wrote:
> Hi Steve,
>
> I am using a 3.10 based kernel, and when I enable function_graph with one
> particular x86_64 machine, I encounter rcu_sched stall.
>
> echo function_graph > /sys/kernel/debug/tracing/current_tracer
> echo 1 > /sys/kernel/
On Thu, Jun 22, 2017 at 11:27:09AM -0600, Alex Williamson wrote:
> On Thu, 22 Jun 2017 22:42:19 +0530
> Nitin Saxena wrote:
>
> > Thanks Alex.
> >
> > >> Without an iommu in the VM, you'd be limited to no-iommu support for VM
> > >> userspace,
> > So are you trying to say VFIO NO-IOMMU should
On Thu, 22 Jun 2017 22:42:19 +0530
Nitin Saxena wrote:
> Thanks Alex.
>
> >> Without an iommu in the VM, you'd be limited to no-iommu support for VM
> >> userspace,
> So are you trying to say VFIO NO-IOMMU should work inside VM. Does
> that mean VFIO NO-IOMMU in VM and VFIO IOMMU in host for
Thanks Alex.
>> Without an iommu in the VM, you'd be limited to no-iommu support for VM
>> userspace,
So are you trying to say VFIO NO-IOMMU should work inside VM. Does
that mean VFIO NO-IOMMU in VM and VFIO IOMMU in host for same device
is a legitimate configuration? I did tried this configurati
[cc +qemu-devel, +peterx]
On Thu, 22 Jun 2017 22:18:06 +0530
Nitin Saxena wrote:
> Hi,
>
> I have a PCI device connected as an endpoint to Intel host machine.
> The requirement is to run dpdk like user space data path application
> in VM using PCI PF passthrough (SRIOV disabled). This applicati
Hi,
On Wednesday 19 April 2017 01:35 AM, Grygorii Strashko wrote:
> + linux-pm
>
> On 04/18/2017 01:07 AM, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> resume_noirq callbacks are used in PCIe core to restore PCI state (this
>> accesses PCI module). So the clocks of PCI module has to be enabled befo
+ linux-pm
On 04/18/2017 01:07 AM, Kishon Vijay Abraham I wrote:
> Hi,
>
> resume_noirq callbacks are used in PCIe core to restore PCI state (this
> accesses PCI module). So the clocks of PCI module has to be enabled before
> resume_noirq.
>
> The clocks for the PCI module in DRA7xx is provided
(Adding Pantelis and dgibson to cc.)
On 03/23/17 11:32, Rob Herring wrote:
> On Thu, Mar 23, 2017 at 8:22 AM, Nava kishore Manne
> wrote:
>> Hi,
>>
>>
>>
>> This mail is regarding the DT overlay support in the Linux
>> kernel
>>
>> I am able to make the device-tree
On Thu, Mar 23, 2017 at 8:22 AM, Nava kishore Manne
wrote:
> Hi,
>
>
>
> This mail is regarding the DT overlay support in the Linux
> kernel
>
> I am able to make the device-tree overlay work out of box by
> using my own dtc complier (I mean I used the dtc compiler
Hi,
This mail is regarding the DT overlay support in the Linux
kernel
I am able to make the device-tree overlay work out of box by
using my own dtc complier (I mean I used the dtc compiler
Available here
http://www.embedded-things.com/bbb/patching
On 9/21/2016 9:26 PM, Akinobu Mita wrote:
> 2016-09-21 23:06 GMT+09:00 Khan, Imran :
>
commit 084ee793ec1ff4e2171b481642bfbdaa2e10664c
Author: Imran Khan
Date: Thu Sep 15 16:44:02 2016 +0530
blk-mq: use static mapping
blk-mq layer performs a remapping
On 8/16/2016 11:23 AM, Khan, Imran wrote:
> On 8/5/2016 12:49 PM, Khan, Imran wrote:
>> On 8/1/2016 2:58 PM, Khan, Imran wrote:
>>> On 7/30/2016 7:54 AM, Akinobu Mita wrote:
2016-07-28 22:18 GMT+09:00 Khan, Imran :
>
> Hi,
>
> Recently we have observed some increased latency in
On 8/5/2016 12:49 PM, Khan, Imran wrote:
> On 8/1/2016 2:58 PM, Khan, Imran wrote:
>> On 7/30/2016 7:54 AM, Akinobu Mita wrote:
>>> 2016-07-28 22:18 GMT+09:00 Khan, Imran :
Hi,
Recently we have observed some increased latency in CPU hotplug
event in CPU online path. For onl
On 8/1/2016 2:58 PM, Khan, Imran wrote:
> On 7/30/2016 7:54 AM, Akinobu Mita wrote:
>> 2016-07-28 22:18 GMT+09:00 Khan, Imran :
>>>
>>> Hi,
>>>
>>> Recently we have observed some increased latency in CPU hotplug
>>> event in CPU online path. For online latency we see that block
>>> layer is executi
On 7/30/2016 7:54 AM, Akinobu Mita wrote:
> 2016-07-28 22:18 GMT+09:00 Khan, Imran :
>>
>> Hi,
>>
>> Recently we have observed some increased latency in CPU hotplug
>> event in CPU online path. For online latency we see that block
>> layer is executing notification handler for CPU_UP_PREPARE event
On (07/29/16 13:42), Viresh Kumar wrote:
[..]
> I haven't seen any issues with it yet and it works just fine. Please feel free
> to add below for the entire series including this hunk.
>
> Tested-by: Viresh Kumar
Thanks a lot!
will refresh the series next week.
sorry, haven't gotten many chance
On 13-07-16, 14:45, Sergey Senozhatsky wrote:
> something like below, perhaps. will this work for you?
>
> ---
> kernel/printk/printk.c | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index bbb4180..786690e 1
On Thu, Jul 21, 2016 at 5:12 PM, pavi1729 wrote:
> Hi,
> signal.h code and a memset of size 0, is that fine or am I missing
> something ?
When _NSIG_WORDS is 1 you enter case 1: which is a nop, so the memset()
is not being executed.
>
> http://lxr.free-electrons.com/source/include/linux/signa
On Monday, July 18, 2016 01:01:34 PM Jan Kara wrote:
> On Thu 14-07-16 15:12:51, Viresh Kumar wrote:
> > On 14-07-16, 16:12, Jan Kara wrote:
> > > Exactly. Calling printk() from certain parts of the kernel (like scheduler
> > > code or timer code) has been always unsafe because printk itself uses
On Thu 14-07-16 15:12:51, Viresh Kumar wrote:
> On 14-07-16, 16:12, Jan Kara wrote:
> > Exactly. Calling printk() from certain parts of the kernel (like scheduler
> > code or timer code) has been always unsafe because printk itself uses these
> > parts and so it can lead to deadlocks. That's why pr
On 15-07-16, 22:11, Sergey Senozhatsky wrote:
> Hello,
>
> On (07/14/16 16:52), Viresh Kumar wrote:
> > On 12-07-16, 23:03, Sergey Senozhatsky wrote:
> > > so, I'm looking at this thing now:
> > >
> > > : [ 12.874909] sched: RT throttling activated for rt_rq
> > > ffc0ac13fcd0 (cpu 0)
> >
Hello,
On (07/14/16 16:52), Viresh Kumar wrote:
> On 12-07-16, 23:03, Sergey Senozhatsky wrote:
> > so, I'm looking at this thing now:
> >
> > : [ 12.874909] sched: RT throttling activated for rt_rq ffc0ac13fcd0
> > (cpu 0)
> > : [ 12.874909] potential CPU hogs:
> > : [ 12.874909] pri
Sorry, but I failed to do any testing on this and answer the questions you
raise. But I saw this again today and here are some important points.
On 12-07-16, 23:03, Sergey Senozhatsky wrote:
> so, I'm looking at this thing now:
>
> : [ 12.874909] sched: RT throttling activated for rt_rq ffc
On 14-07-16, 16:55, Jan Kara wrote:
> Agree on that - but that seems to be a problem of a particular wakeup
> implementation of the 3.10 kernel Viresh is using, not a problem of the
> upstream kernel.
I think we can get it to trigger on mainline as well. Also to mention that I
also don't see it on
On 14-07-16, 16:12, Jan Kara wrote:
> Exactly. Calling printk() from certain parts of the kernel (like scheduler
> code or timer code) has been always unsafe because printk itself uses these
> parts and so it can lead to deadlocks. That's why printk_deffered() has
> been introduced as you mention b
1 - 100 of 441 matches
Mail list logo
