3.16.55-stable breaks yeeloong

3.16.55-stable breaks yeeloong

[Alexandre Oliva]

Commit 304acb717e5b67cf56f05bc5b21123758e1f7ea0 AKA
https://patchwork.linux-mips.org/patch/9705/ was backported to 3.16.55
stable as 8605aa2fea28c0485aeb60c114a9d52df1455915 and I'm afraid it
causes yeeloongs to fail to boot up.  3.16.54 was fine; bisection took
me to this patch.

The symptom is a kernel panic -- attempt to kill init.  No further info
is provided.

Is this problem already known?  Is there by any chance a known fix for
me to try, or should I investigate further?

Thanks in advance,

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer

Re: 3.16.55-stable breaks yeeloong

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 912 bytes --]

On Sun, 2018-03-18 at 11:06 -0300, Alexandre Oliva wrote:
> Commit 304acb717e5b67cf56f05bc5b21123758e1f7ea0 AKA
> https://patchwork.linux-mips.org/patch/9705/ was backported to 3.16.55
> stable as 8605aa2fea28c0485aeb60c114a9d52df1455915 and I'm afraid it
> causes yeeloongs to fail to boot up.  3.16.54 was fine; bisection took
> me to this patch.
> 
> The symptom is a kernel panic -- attempt to kill init.  No further info
> is provided.
> 
> Is this problem already known?  Is there by any chance a known fix for
> me to try, or should I investigate further?

Guenter Roeck reported the same problem on QEMU Malta emulation.
I haven't yet ivnestigated why this causes breakage.  I will aim to fix
this in the next update (will be 3.16.57 now), if necessary by
reverting that and whatever depends on it.

Ben.

-- 
Ben Hutchings
Logic doesn't apply to the real world. - Marvin Minsky


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: 3.16.55-stable breaks yeeloong

[Maciej W. Rozycki]

On Sun, 18 Mar 2018, Ben Hutchings wrote:

> > Commit 304acb717e5b67cf56f05bc5b21123758e1f7ea0 AKA
> > https://patchwork.linux-mips.org/patch/9705/ was backported to 3.16.55
> > stable as 8605aa2fea28c0485aeb60c114a9d52df1455915 and I'm afraid it
> > causes yeeloongs to fail to boot up.  3.16.54 was fine; bisection took
> > me to this patch.
> > 
> > The symptom is a kernel panic -- attempt to kill init.  No further info
> > is provided.
> > 
> > Is this problem already known?  Is there by any chance a known fix for
> > me to try, or should I investigate further?
> 
> Guenter Roeck reported the same problem on QEMU Malta emulation.
> I haven't yet ivnestigated why this causes breakage.  I will aim to fix
> this in the next update (will be 3.16.57 now), if necessary by
> reverting that and whatever depends on it.

 I'll see if I can trigger it with my development setup and investigate.

  Maciej

Re: 3.16.55-stable breaks yeeloong

[Maciej W. Rozycki]

On Sun, 18 Mar 2018, Ben Hutchings wrote:

> > Commit 304acb717e5b67cf56f05bc5b21123758e1f7ea0 AKA
> > https://patchwork.linux-mips.org/patch/9705/ was backported to 3.16.55
> > stable as 8605aa2fea28c0485aeb60c114a9d52df1455915 and I'm afraid it
> > causes yeeloongs to fail to boot up.  3.16.54 was fine; bisection took
> > me to this patch.
> > 
> > The symptom is a kernel panic -- attempt to kill init.  No further info
> > is provided.
> > 
> > Is this problem already known?  Is there by any chance a known fix for
> > me to try, or should I investigate further?
> 
> Guenter Roeck reported the same problem on QEMU Malta emulation.
> I haven't yet ivnestigated why this causes breakage.  I will aim to fix
> this in the next update (will be 3.16.57 now), if necessary by
> reverting that and whatever depends on it.

 I'll see if I can trigger it with my development setup and investigate.

  Maciej

Re: 3.16.55-stable breaks yeeloong

[Maciej W. Rozycki]

On Mon, 19 Mar 2018, Maciej W. Rozycki wrote:

> > > Commit 304acb717e5b67cf56f05bc5b21123758e1f7ea0 AKA
> > > https://patchwork.linux-mips.org/patch/9705/ was backported to 3.16.55
> > > stable as 8605aa2fea28c0485aeb60c114a9d52df1455915 and I'm afraid it
> > > causes yeeloongs to fail to boot up.  3.16.54 was fine; bisection took
> > > me to this patch.
[...]
> > Guenter Roeck reported the same problem on QEMU Malta emulation.
> > I haven't yet ivnestigated why this causes breakage.  I will aim to fix
> > this in the next update (will be 3.16.57 now), if necessary by
> > reverting that and whatever depends on it.
> 
>  I'll see if I can trigger it with my development setup and investigate.

 OK, I have been able to reproduce the crash and I can see what is going 
on here: the backport didn't take into account a change from `break' to 
`goto out' required for code in `do_cpu' in that old version and 
consequently `force_sig(SIGILL, current)' is reached whenever the first 
FPU instruction is executed on hard-float hardware, with obvious 
consequences.

 Rather than messing with commit 304acb717e5b ("MIPS: Set `si_code' for 
SIGFPE signals sent from emulation too") though, I suggest cherry-picking 
commit 27e28e8ec47a ("MIPS: Normalise code flow in the CpU exception 
handler"), which was in the original series and which I have verified to 
remove the crash.  I believe it is obvious enough to be considered safe to 
backport.

 Please let me know if you need anything else from me.

  Maciej

Re: 3.16.55-stable breaks yeeloong

[Maciej W. Rozycki]

On Mon, 19 Mar 2018, Maciej W. Rozycki wrote:

> > > Commit 304acb717e5b67cf56f05bc5b21123758e1f7ea0 AKA
> > > https://patchwork.linux-mips.org/patch/9705/ was backported to 3.16.55
> > > stable as 8605aa2fea28c0485aeb60c114a9d52df1455915 and I'm afraid it
> > > causes yeeloongs to fail to boot up.  3.16.54 was fine; bisection took
> > > me to this patch.
[...]
> > Guenter Roeck reported the same problem on QEMU Malta emulation.
> > I haven't yet ivnestigated why this causes breakage.  I will aim to fix
> > this in the next update (will be 3.16.57 now), if necessary by
> > reverting that and whatever depends on it.
> 
>  I'll see if I can trigger it with my development setup and investigate.

 OK, I have been able to reproduce the crash and I can see what is going 
on here: the backport didn't take into account a change from `break' to 
`goto out' required for code in `do_cpu' in that old version and 
consequently `force_sig(SIGILL, current)' is reached whenever the first 
FPU instruction is executed on hard-float hardware, with obvious 
consequences.

 Rather than messing with commit 304acb717e5b ("MIPS: Set `si_code' for 
SIGFPE signals sent from emulation too") though, I suggest cherry-picking 
commit 27e28e8ec47a ("MIPS: Normalise code flow in the CpU exception 
handler"), which was in the original series and which I have verified to 
remove the crash.  I believe it is obvious enough to be considered safe to 
backport.

 Please let me know if you need anything else from me.

  Maciej

Re: 3.16.55-stable breaks yeeloong

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1894 bytes --]

On Mon, 2018-03-19 at 22:52 +0000, Maciej W. Rozycki wrote:
> On Mon, 19 Mar 2018, Maciej W. Rozycki wrote:
> 
> > > > Commit 304acb717e5b67cf56f05bc5b21123758e1f7ea0 AKA
> > > > https://patchwork.linux-mips.org/patch/9705/ was backported to 3.16.55
> > > > stable as 8605aa2fea28c0485aeb60c114a9d52df1455915 and I'm afraid it
> > > > causes yeeloongs to fail to boot up.  3.16.54 was fine; bisection took
> > > > me to this patch.
> 
> [...]
> > > Guenter Roeck reported the same problem on QEMU Malta emulation.
> > > I haven't yet ivnestigated why this causes breakage.  I will aim to fix
> > > this in the next update (will be 3.16.57 now), if necessary by
> > > reverting that and whatever depends on it.
> > 
> >  I'll see if I can trigger it with my development setup and investigate.
> 
>  OK, I have been able to reproduce the crash and I can see what is going 
> on here: the backport didn't take into account a change from `break' to 
> `goto out' required for code in `do_cpu' in that old version and 
> consequently `force_sig(SIGILL, current)' is reached whenever the first 
> FPU instruction is executed on hard-float hardware, with obvious 
> consequences.
> 
>  Rather than messing with commit 304acb717e5b ("MIPS: Set `si_code' for 
> SIGFPE signals sent from emulation too") though, I suggest cherry-picking 
> commit 27e28e8ec47a ("MIPS: Normalise code flow in the CpU exception 
> handler"), which was in the original series and which I have verified to 
> remove the crash.  I believe it is obvious enough to be considered safe to 
> backport.

I started looking at this today and also found that commit, but hadn't
tested it yet.  Thanks for confirming.

Ben.

>  Please let me know if you need anything else from me.
> 
>   Maciej
-- 
Ben Hutchings
Time is nature's way of making sure that
everything doesn't happen at once.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]