On Mon 2017-07-17 13:01:58, Linus Torvalds wrote:
> On Sat, Jul 15, 2017 at 1:24 PM, Pavel Machek wrote:
> >
> > But I don't see the commit in 4.13-rc0. Could we get it in now, so
> > that problem is fixed in -rc1?
>
> It didn't hit rc1, but it's in my tree now.
Thanks for head-up. Yes, current
On Sat, Jul 15, 2017 at 1:24 PM, Pavel Machek wrote:
>
> But I don't see the commit in 4.13-rc0. Could we get it in now, so
> that problem is fixed in -rc1?
It didn't hit rc1, but it's in my tree now.
Linus
* Pavel Machek [170715 13:24]:
> Hi!
>
> > > On Tue, Jul 11, 2017 at 11:41:52PM +0200, Thomas Gleixner wrote:
> > > > [...]
> > > >
> > > > Here is a revised version of the previous patch with the conditional
> > > > locking removed and a bunch of comments added.
> > >
> > > That one also fixes
Hi!
> > On Tue, Jul 11, 2017 at 11:41:52PM +0200, Thomas Gleixner wrote:
> > > [...]
> > >
> > > Here is a revised version of the previous patch with the conditional
> > > locking removed and a bunch of comments added.
> >
> > That one also fixes Droid 4 boot.
> >
> > Tested-by: Sebastian Reiche
Hi Grygorii,
On Tue, Jul 11, 2017 at 5:39 PM, Grygorii Strashko
wrote:
> On 07/11/2017 09:41 AM, Thomas Gleixner wrote:
>> On Tue, 11 Jul 2017, Tony Lindgren wrote:
>>> * Thomas Gleixner [170711 02:48]:
>>> And "external abort on non-linefetch" means something is not clocked
>>> in this case. Th
* Sebastian Reichel [170711 15:51]:
> Hi,
>
> On Tue, Jul 11, 2017 at 11:41:52PM +0200, Thomas Gleixner wrote:
> > [...]
> >
> > Here is a revised version of the previous patch with the conditional
> > locking removed and a bunch of comments added.
>
> That one also fixes Droid 4 boot.
>
> Test
Hi,
On Tue, Jul 11, 2017 at 11:41:52PM +0200, Thomas Gleixner wrote:
> [...]
>
> Here is a revised version of the previous patch with the conditional
> locking removed and a bunch of comments added.
That one also fixes Droid 4 boot.
Tested-by: Sebastian Reichel
-- Sebastian
> 8<--
On Tue, Jul 11, 2017 at 2:41 PM, Thomas Gleixner wrote:
>
> Here is a revised version of the previous patch with the conditional
> locking removed and a bunch of comments added.
This one looks good to me. Thanks,
Linus
On Tue, 11 Jul 2017, Linus Torvalds wrote:
> On Tue, Jul 11, 2017 at 10:52 AM, Thomas Gleixner wrote:
> >
> > Not completely, because of the free path issues. See the other mail. Tony
> > confirmed that it works. I wait for Sebastian and queue it with a proper
> > changelog, ok?
>
> Ugh, I absol
Hi,
On Tue, Jul 11, 2017 at 11:16:03AM -0700, Linus Torvalds wrote:
> On Tue, Jul 11, 2017 at 10:52 AM, Thomas Gleixner wrote:
> > Not completely, because of the free path issues. See the other mail. Tony
> > confirmed that it works. I wait for Sebastian and queue it with a proper
> > changelog,
On Tue, Jul 11, 2017 at 10:52 AM, Thomas Gleixner wrote:
>
> Not completely, because of the free path issues. See the other mail. Tony
> confirmed that it works. I wait for Sebastian and queue it with a proper
> changelog, ok?
Ugh, I absolutely detest your ugly "bool buslock" parameter to
irq_rel
On Tue, 11 Jul 2017, Linus Torvalds wrote:
> On Tue, Jul 11, 2017 at 9:19 AM, Thomas Gleixner wrote:
> >
> > What I do not understand here is that we have already power management
> > around all of that.
> >
> >irq_chip_pm_get(&desc->irq_data);
> >...
> >chip_bus_lock(desc)
* Thomas Gleixner [170711 10:17]:
> On Tue, 11 Jul 2017, Tony Lindgren wrote:
> > * Linus Torvalds [170711 08:40]:
> > > On Tue, Jul 11, 2017 at 7:41 AM, Thomas Gleixner
> > > wrote:
> > > >
> > > > Ah. Now that makes sense.
> > > >
> > > > Unpatched the ordering is:
> > > >
> > > > c
On Tue, 11 Jul 2017, Tony Lindgren wrote:
> * Linus Torvalds [170711 08:40]:
> > On Tue, Jul 11, 2017 at 7:41 AM, Thomas Gleixner wrote:
> > >
> > > Ah. Now that makes sense.
> > >
> > > Unpatched the ordering is:
> > >
> > > chip_bus_lock(desc);
> > > irq_request_resources(de
Hi,
On Tue, Jul 11, 2017 at 09:20:44AM -0700, Tony Lindgren wrote:
> * Sebastian Reichel [170711 07:41]:
> > Ack, that also works for me. The strange thing is, that I added the
> > following before and it did not print anything.
> >
> > if (!pm_runtime_enabled(bank->chip.parent))
> > dev_err
* Thomas Gleixner [170711 09:20]:
> On Tue, 11 Jul 2017, Linus Torvalds wrote:
>
> > On Tue, Jul 11, 2017 at 7:41 AM, Thomas Gleixner wrote:
> > >
> > > Ah. Now that makes sense.
> > >
> > > Unpatched the ordering is:
> > >
> > > chip_bus_lock(desc);
> > > irq_request_resourc
On Tue, Jul 11, 2017 at 9:19 AM, Thomas Gleixner wrote:
>
> What I do not understand here is that we have already power management
> around all of that.
>
>irq_chip_pm_get(&desc->irq_data);
>...
>chip_bus_lock(desc);
>...
>chip_bus_unlock_sync(desc);
>
* Sebastian Reichel [170711 07:41]:
> Ack, that also works for me. The strange thing is, that I added the
> following before and it did not print anything.
>
> if (!pm_runtime_enabled(bank->chip.parent))
> dev_err(bank->chip.parent, "runtime pm issue!\n");
Enabled but not active, you should
On Tue, 11 Jul 2017, Linus Torvalds wrote:
> On Tue, Jul 11, 2017 at 7:41 AM, Thomas Gleixner wrote:
> >
> > Ah. Now that makes sense.
> >
> > Unpatched the ordering is:
> >
> > chip_bus_lock(desc);
> > irq_request_resources(desc);
>
> I *looked* at that ordering and then wen
* Grygorii Strashko [170711 08:40]:
> Tony, Potentially we can use pm_runtime_force_suspend()/resume() there, but
> they are not compatible with
> irqoff context (CPUIdle late stages).
>
> In other words, below patch should fix this issue, but will break CPUIdle on
> OMAP :(
Thanks, yea let's
Hi,
On Tue, Jul 11, 2017 at 08:40:10AM -0700, Linus Torvalds wrote:
> On Tue, Jul 11, 2017 at 7:41 AM, Thomas Gleixner wrote:
> >
> > Ah. Now that makes sense.
> >
> > Unpatched the ordering is:
> >
> > chip_bus_lock(desc);
> > irq_request_resources(desc);
>
> I *looked* at t
* Linus Torvalds [170711 08:40]:
> On Tue, Jul 11, 2017 at 7:41 AM, Thomas Gleixner wrote:
> >
> > Ah. Now that makes sense.
> >
> > Unpatched the ordering is:
> >
> > chip_bus_lock(desc);
> > irq_request_resources(desc);
>
> I *looked* at that ordering and then went "Naah, t
* Thomas Gleixner [170711 08:07]:
> On Tue, 11 Jul 2017, Thomas Gleixner wrote:
> > On Tue, 11 Jul 2017, Tony Lindgren wrote:
> > > * Thomas Gleixner [170711 02:48]:
> > > And "external abort on non-linefetch" means something is not clocked
> > > in this case. The following alone makes things boo
On Tue, Jul 11, 2017 at 7:41 AM, Thomas Gleixner wrote:
>
> Ah. Now that makes sense.
>
> Unpatched the ordering is:
>
> chip_bus_lock(desc);
> irq_request_resources(desc);
I *looked* at that ordering and then went "Naah, that makes no sense".
But if that's the only issue, ho
On 07/11/2017 09:41 AM, Thomas Gleixner wrote:
> On Tue, 11 Jul 2017, Tony Lindgren wrote:
>> * Thomas Gleixner [170711 02:48]:
>> And "external abort on non-linefetch" means something is not clocked
>> in this case. The following alone makes things boot for me again, but I don't
>> quite follow
On Tue, 11 Jul 2017, Thomas Gleixner wrote:
> On Tue, 11 Jul 2017, Tony Lindgren wrote:
> > * Thomas Gleixner [170711 02:48]:
> > And "external abort on non-linefetch" means something is not clocked
> > in this case. The following alone makes things boot for me again, but I
> > don't
> > quite fo
Hi,
On Tue, Jul 11, 2017 at 06:51:32AM -0700, Tony Lindgren wrote:
> * Thomas Gleixner [170711 02:48]:
> > On Tue, 11 Jul 2017, Thomas Gleixner wrote:
> >
> > So Tony actually provided the part of dmesg which shows the initial
> > failure, which subsequently leads to the splat Sebastian reported
On Tue, 11 Jul 2017, Tony Lindgren wrote:
> * Thomas Gleixner [170711 02:48]:
> And "external abort on non-linefetch" means something is not clocked
> in this case. The following alone makes things boot for me again, but I don't
> quite follow what has now changed with the ordering.. Thomas, any i
Hi,
On Tue, Jul 11, 2017 at 02:51:23PM +0100, Marc Zyngier wrote:
> On 11/07/17 12:21, Sebastian Reichel wrote:
> > Hi,
> >
> > On Tue, Jul 11, 2017 at 12:52:17PM +0200, Thomas Gleixner wrote:
> >> On Tue, 11 Jul 2017, Thomas Gleixner wrote:
> >>> On Tue, 11 Jul 2017, Sebastian Reichel wrote:
> >
* Thomas Gleixner [170711 02:48]:
> On Tue, 11 Jul 2017, Thomas Gleixner wrote:
>
> So Tony actually provided the part of dmesg which shows the initial
> failure, which subsequently leads to the splat Sebastian reported.
>
> Unhandled fault: external abort on non-linefetch (0x1028) at 0xfb050034
On 11/07/17 12:21, Sebastian Reichel wrote:
> Hi,
>
> On Tue, Jul 11, 2017 at 12:52:17PM +0200, Thomas Gleixner wrote:
>> On Tue, 11 Jul 2017, Thomas Gleixner wrote:
>>> On Tue, 11 Jul 2017, Sebastian Reichel wrote:
>>> So this crashes in do_raw_spin_unlock_irqrestore() !?! I just have to
>>> wond
On Tue, 11 Jul 2017, Sebastian Reichel wrote:
> On Tue, Jul 11, 2017 at 12:52:17PM +0200, Thomas Gleixner wrote:
> > On Tue, 11 Jul 2017, Thomas Gleixner wrote:
> > > On Tue, 11 Jul 2017, Sebastian Reichel wrote:
> > > So this crashes in do_raw_spin_unlock_irqrestore() !?! I just have to
> > > wond
Hi,
On Tue, Jul 11, 2017 at 12:52:17PM +0200, Thomas Gleixner wrote:
> On Tue, 11 Jul 2017, Thomas Gleixner wrote:
> > On Tue, 11 Jul 2017, Sebastian Reichel wrote:
> > So this crashes in do_raw_spin_unlock_irqrestore() !?! I just have to
> > wonder how the raw_spin_lock() succeeded. That does not
Sebastian,
On Tue, 11 Jul 2017, Thomas Gleixner wrote:
> On Tue, 11 Jul 2017, Sebastian Reichel wrote:
> So this crashes in do_raw_spin_unlock_irqrestore() !?! I just have to
> wonder how the raw_spin_lock() succeeded. That does not make any sense.
can you please apply the patch below on top of 4
On Tue, 11 Jul 2017, Sebastian Reichel wrote:
> There you go (this is basically 9967468c0a10). The referenced
> cpcap is a PMIC, that uses one of OMAP's GPIOs to generate
> interrupts and (among other things) provides an interrupt
> controller.
>
> [1.328521] cpcap-core spi1.0: CPCAP vendor: S
On Tue, 11 Jul 2017, Thomas Gleixner wrote:
> On Mon, 10 Jul 2017, Linus Torvalds wrote:
> > On Mon, Jul 10, 2017 at 6:35 AM, Sebastian Reichel
> > wrote:
> > >
> > > This patch apparently breaks OMAP platform:
> > >
> > > 46e48e257360f0845fe17089713cbad4db611e70 is the first bad commit
> > > comm
On Mon, 10 Jul 2017, Linus Torvalds wrote:
> On Mon, Jul 10, 2017 at 6:35 AM, Sebastian Reichel
> wrote:
> >
> > This patch apparently breaks OMAP platform:
> >
> > 46e48e257360f0845fe17089713cbad4db611e70 is the first bad commit
> > commit 46e48e257360f0845fe17089713cbad4db611e70
> > Author: Thom
On Mon, Jul 10, 2017 at 1:15 PM, Sebastian Reichel
wrote:
>>
>> So Sebastian, can you test if it's ok to revert just the __setup_irq()
>> part, but leave the smaller part in __free_irq() that just moves the
>> irq_release_resources() around at freeing time?
>
> Looking at my patch it implements wh
Hi Linus,
On Mon, Jul 10, 2017 at 10:01:22AM -0700, Linus Torvalds wrote:
> On Mon, Jul 10, 2017 at 6:35 AM, Sebastian Reichel
> wrote:
> >
> > This patch apparently breaks OMAP platform:
> >
> > 46e48e257360f0845fe17089713cbad4db611e70 is the first bad commit
> > commit 46e48e257360f0845fe170897
Hi!
> > This patch apparently breaks OMAP platform:
> >
> > 46e48e257360f0845fe17089713cbad4db611e70 is the first bad commit
> > commit 46e48e257360f0845fe17089713cbad4db611e70
> > Author: Thomas Gleixner
> > Date: Thu Jun 29 23:33:38 2017 +0200
> >
> > genirq: Move irq resource handling ou
On Mon, Jul 10, 2017 at 6:35 AM, Sebastian Reichel
wrote:
>
> This patch apparently breaks OMAP platform:
>
> 46e48e257360f0845fe17089713cbad4db611e70 is the first bad commit
> commit 46e48e257360f0845fe17089713cbad4db611e70
> Author: Thomas Gleixner
> Date: Thu Jun 29 23:33:38 2017 +0200
>
>
Hi,
On Sun, Jul 09, 2017 at 10:49:57AM +0200, Thomas Gleixner wrote:
> - Move the interrupt resource management logic out of the spin locked,
> irq disabled region to avoid unnecessary restrictions of the resource
> callbacks
This patch apparently breaks OMAP platform:
46e48e257360f084
Linus,
please pull the latest irq-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
irq-urgent-for-linus
This update contains:
- A few fixes mopping up the fallout of the big irq overhaul
- Move the interrupt resource management logic out of the
On 7/4/2017 11:48 PM, Max Gurtovoy wrote:
On 7/4/2017 10:10 PM, Thomas Gleixner wrote:
On Tue, 4 Jul 2017, Linus Torvalds wrote:
On Tue, Jul 4, 2017 at 8:17 AM, Jens Axboe wrote:
On 07/03/2017 06:00 PM, Linus Torvalds wrote:
If they ever do come online, does that get fixed? I don't know
On Mon, Jul 03, 2017 at 05:00:03PM -0700, Linus Torvalds wrote:
> I'm not at all understanding why that second commit came in through
> the irq tree at all, in fact. Very annoying. Why was that not sent
> through the block tree? It doesn't seem to have anything fundamentally
> to do with irqs, real
On 07/04/2017 12:34 PM, Linus Torvalds wrote:
> On Tue, Jul 4, 2017 at 8:17 AM, Jens Axboe wrote:
>> On 07/03/2017 06:00 PM, Linus Torvalds wrote:
>>>
>>> If they ever do come online, does that get fixed? I don't know.
>>> Somebody should check.
>>
>> Yes, the blk-mq cpu hotplug code updates mappi
On 7/4/2017 10:10 PM, Thomas Gleixner wrote:
On Tue, 4 Jul 2017, Linus Torvalds wrote:
On Tue, Jul 4, 2017 at 8:17 AM, Jens Axboe wrote:
On 07/03/2017 06:00 PM, Linus Torvalds wrote:
If they ever do come online, does that get fixed? I don't know.
Somebody should check.
Yes, the blk-mq cp
On Tue, 4 Jul 2017, Linus Torvalds wrote:
> On Tue, Jul 4, 2017 at 8:17 AM, Jens Axboe wrote:
> > On 07/03/2017 06:00 PM, Linus Torvalds wrote:
> >>
> >> If they ever do come online, does that get fixed? I don't know.
> >> Somebody should check.
> >
> > Yes, the blk-mq cpu hotplug code updates map
On Tue, Jul 4, 2017 at 8:17 AM, Jens Axboe wrote:
> On 07/03/2017 06:00 PM, Linus Torvalds wrote:
>>
>> If they ever do come online, does that get fixed? I don't know.
>> Somebody should check.
>
> Yes, the blk-mq cpu hotplug code updates mappings when CPUs come and
> go, so that part is fine. Tha
On 07/03/2017 06:00 PM, Linus Torvalds wrote:
> But I'd like people to look at that - not so much due to the evil
> merge itself (but check that too, by any means), but just because the
> code seems fundamentally broken for the hotplug case. We end up
> picking a possible metric shit-ton of CPU's f
On Tue, 4 Jul 2017, Thomas Gleixner wrote:
> On Mon, 3 Jul 2017, Linus Torvalds wrote:
>
> > On Mon, Jul 3, 2017 at 12:42 AM, Thomas Gleixner wrote:
> > >
> > > please pull the latest irq-core-for-linus git tree from:
> > >
> > >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> > >
On Mon, 3 Jul 2017, Linus Torvalds wrote:
> On Mon, Jul 3, 2017 at 12:42 AM, Thomas Gleixner wrote:
> >
> > please pull the latest irq-core-for-linus git tree from:
> >
> >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> > irq-core-for-linus
>
> Ugh, this caused conflicts with th
On Mon, Jul 3, 2017 at 12:42 AM, Thomas Gleixner wrote:
>
> please pull the latest irq-core-for-linus git tree from:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> irq-core-for-linus
Ugh, this caused conflicts with the block tree, with commits
- fe631457ff3e: "blk-mq: map a
Linus,
please pull the latest irq-core-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq-core-for-linus
The irq department delivers:
- Expand the generic infrastructure handling the irq migration on CPU
hotplug and convert X86 over to it. (Thoma
54 matches
Mail list logo
