On 31/01/15 10:21, Daniel Lezcano wrote:
On 01/31/2015 02:08 AM, Stephen Boyd wrote:
Kept meaning to get back to this thread. Have you resolved it?
On 10/29/14 03:38, Marcin Jabrzyk wrote:
So I've tried this patch, it resolves one problem but introduces also
new ones. As expected the BUG
On 31/01/15 10:21, Daniel Lezcano wrote:
On 01/31/2015 02:08 AM, Stephen Boyd wrote:
Kept meaning to get back to this thread. Have you resolved it?
On 10/29/14 03:38, Marcin Jabrzyk wrote:
So I've tried this patch, it resolves one problem but introduces also
new ones. As expected the BUG
On 01/31/2015 02:08 AM, Stephen Boyd wrote:
Kept meaning to get back to this thread. Have you resolved it?
On 10/29/14 03:38, Marcin Jabrzyk wrote:
So I've tried this patch, it resolves one problem but introduces also
new ones. As expected the BUG warning is not showing after applying
this
On 01/31/2015 02:08 AM, Stephen Boyd wrote:
Kept meaning to get back to this thread. Have you resolved it?
On 10/29/14 03:38, Marcin Jabrzyk wrote:
So I've tried this patch, it resolves one problem but introduces also
new ones. As expected the BUG warning is not showing after applying
this
Kept meaning to get back to this thread. Have you resolved it?
On 10/29/14 03:38, Marcin Jabrzyk wrote:
> So I've tried this patch, it resolves one problem but introduces also
> new ones. As expected the BUG warning is not showing after applying
> this patch but there are some interesting side
Kept meaning to get back to this thread. Have you resolved it?
On 10/29/14 03:38, Marcin Jabrzyk wrote:
So I've tried this patch, it resolves one problem but introduces also
new ones. As expected the BUG warning is not showing after applying
this patch but there are some interesting side
So I've tried this patch, it resolves one problem but introduces also
new ones. As expected the BUG warning is not showing after applying this
patch but there are some interesting side effects.
I was looking on /proc/interrupts output. IRQ for CPU0 have "MCT" name
and IRQ for CPU1 has
So I've tried this patch, it resolves one problem but introduces also
new ones. As expected the BUG warning is not showing after applying this
patch but there are some interesting side effects.
I was looking on /proc/interrupts output. IRQ for CPU0 have MCT name
and IRQ for CPU1 has
On 10/24/2014 06:22 AM, Marcin Jabrzyk wrote:
>
>
> On 23/10/14 20:41, Stephen Boyd wrote:
>> On 10/23/2014 07:06 AM, Russell King - ARM Linux wrote:
>>> The CPU notifier is called via notify_cpu_starting(), which is called
>>> with interrupts disabled, and a reason code of CPU_STARTING.
>>>
On 10/24/2014 06:22 AM, Marcin Jabrzyk wrote:
On 23/10/14 20:41, Stephen Boyd wrote:
On 10/23/2014 07:06 AM, Russell King - ARM Linux wrote:
The CPU notifier is called via notify_cpu_starting(), which is called
with interrupts disabled, and a reason code of CPU_STARTING.
Interrupts
at
On 23/10/14 20:41, Stephen Boyd wrote:
On 10/23/2014 07:06 AM, Russell King - ARM Linux wrote:
On Thu, Oct 23, 2014 at 03:51:16PM +0200, Marcin Jabrzyk wrote:
[1.] One line summary of the problem: "BUG: sleeping function called from
invalid context at mm/slub.c:1250" after CPU hotplug
I'm
On 23/10/14 20:41, Stephen Boyd wrote:
On 10/23/2014 07:06 AM, Russell King - ARM Linux wrote:
On Thu, Oct 23, 2014 at 03:51:16PM +0200, Marcin Jabrzyk wrote:
[1.] One line summary of the problem: BUG: sleeping function called from
invalid context at mm/slub.c:1250 after CPU hotplug
I'm
On 10/23/2014 07:06 AM, Russell King - ARM Linux wrote:
> On Thu, Oct 23, 2014 at 03:51:16PM +0200, Marcin Jabrzyk wrote:
>> [1.] One line summary of the problem: "BUG: sleeping function called from
>> invalid context at mm/slub.c:1250" after CPU hotplug
> I'm really not surprised.
>
>> When SoC
On Thu, Oct 23, 2014 at 03:51:16PM +0200, Marcin Jabrzyk wrote:
> [1.] One line summary of the problem: "BUG: sleeping function called from
> invalid context at mm/slub.c:1250" after CPU hotplug
I'm really not surprised.
> When SoC have MCT_INT_SPI interrupt it is being allocated after
[1.] One line summary of the problem: "BUG: sleeping function called
from invalid context at mm/slub.c:1250" after CPU hotplug
[2.] Full description of the problem/report:
This was tested on Exynos 3250 board with
https://lkml.org/lkml/2014/9/24/441 applied. Board is booting to
/bin/sh. After
[1.] One line summary of the problem: BUG: sleeping function called
from invalid context at mm/slub.c:1250 after CPU hotplug
[2.] Full description of the problem/report:
This was tested on Exynos 3250 board with
https://lkml.org/lkml/2014/9/24/441 applied. Board is booting to
/bin/sh. After
On Thu, Oct 23, 2014 at 03:51:16PM +0200, Marcin Jabrzyk wrote:
[1.] One line summary of the problem: BUG: sleeping function called from
invalid context at mm/slub.c:1250 after CPU hotplug
I'm really not surprised.
When SoC have MCT_INT_SPI interrupt it is being allocated after hotplugging
On 10/23/2014 07:06 AM, Russell King - ARM Linux wrote:
On Thu, Oct 23, 2014 at 03:51:16PM +0200, Marcin Jabrzyk wrote:
[1.] One line summary of the problem: BUG: sleeping function called from
invalid context at mm/slub.c:1250 after CPU hotplug
I'm really not surprised.
When SoC have
18 matches
Mail list logo
