Thiago Jung Bauermann writes:
> Am Dienstag, 7. Februar 2017, 08:26:45 BRST schrieb Balbir Singh:
>> On Mon, Feb 06, 2017 at 04:58:16PM -0200, Thiago Jung Bauermann wrote:
>> > [ 447.714064] Querying DEAD? cpu 134 (134) shows 2
>> > cpu 0x86: Vector: 300 (Data Access) at [c7b0fd40]
>> >
Am Dienstag, 7. Februar 2017, 08:26:45 BRST schrieb Balbir Singh:
> On Mon, Feb 06, 2017 at 04:58:16PM -0200, Thiago Jung Bauermann wrote:
> > [ 447.714064] Querying DEAD? cpu 134 (134) shows 2
> > cpu 0x86: Vector: 300 (Data Access) at [c7b0fd40]
> >
> > pc: 1ec3072c
> >
On Mon, Feb 06, 2017 at 04:58:16PM -0200, Thiago Jung Bauermann wrote:
> [ 447.714064] Querying DEAD? cpu 134 (134) shows 2
> cpu 0x86: Vector: 300 (Data Access) at [c7b0fd40]
> pc: 1ec3072c
> lr: 1ec2fee0
> sp: 1faf6bd0
>msr: 800102801000
>dar: 212d
Thiago Jung Bauermann writes:
> When testing DLPAR CPU add/remove on a system under stress, pseries_cpu_die
> doesn't wait long enough for a CPU to die and the kernel ends up crashing:
>
> [ 446.143648] cpu 152 (hwid 152) Ready to die...
> [ 446.464057] cpu 153 (hwid 153) Ready to die...
> [ 4
On Mon, Feb 06, 2017 at 04:58:16PM -0200, Thiago Jung Bauermann wrote:
> This was reproduced in v4.10-rc6 as well, but I don't have a crash log
> handy for that version right now. Sorry.
>
This is the crash log of v4.10:
roselp4 login: [ 505.097727] sysrq: SysRq : Changing Loglevel
[ 505.097743
When testing DLPAR CPU add/remove on a system under stress, pseries_cpu_die
doesn't wait long enough for a CPU to die and the kernel ends up crashing:
[ 446.143648] cpu 152 (hwid 152) Ready to die...
[ 446.464057] cpu 153 (hwid 153) Ready to die...
[ 446.473525] cpu 154 (hwid 154) Ready to die.