Bug#820567: kexec on mipsel partially broken between ckt20 and ckt25
On Sun, Apr 10, 2016 at 07:47:28PM +0100, Ben Hutchings wrote:
> On Sun, 2016-04-10 at 11:09 -0700, Elliott Mitchell wrote:
> > On Sun, Apr 10, 2016 at 10:09:38AM +0100, Ben Hutchings wrote:
> > >
> > > On Sat, 2016-04-09 at 18:31 -0700, Elliott Mitchell wrote:
> > > >
> > > > Between 3.16.7-ctk20 and 3.16.7-ctk25 the kexec functionality of the
> > > > Linux kernel was damaged.????The system I'm looking at uses a 3.3 kernel
> > > > to load the "real" kernel off a filesystem and kexec into that.????The 3.3
> > > > kernel was able to successfully kexec into a 3.16.7-ctk20 kernel, but
> > > > is unable to kexec into a 3.16.7-ctk25 kernel.????However I found the
> > > > 3.16.7-ctk20 IS able to successfully kexec the 3.16.7-ctk25 kernel.
> > > Surely this is a bug in the built-in (3.3) kernel, not the new one? ??If
> > > there's something simple that can be done in the Debian kernel to work
> > > around this, we should do that, but otherwise you're stuck with this.
> > This is certainly a reasonable theory.????Alas, I cannot speak to which of
> > these theories is correct.????All I can say for certain is that something
> > changed between ctk20 and ctk25 which made the 3.3 kernel unable to kexec
> > ctk25.????I'm under the impression as of 3.3 the kexec functionality was
> > supposed to be stable on MIPS, but that could be incorrect.
> >
> > I should also note, during the failed kexecs I would see the messages
> > from the 3.3 kernel saying the kexec was starting, but never see any
> > messages from the ctk25 kernel.????Unless someone wants to send me a JTAG
> > decoder that is all I can say.
>
> One of the MIPS porters may be able to help you, but I have no idea
> what to suggest.
>
> Are you using one of the linux-image packages or building from source
> with your own configuration? ??In the latter case, are you sure you used
> the same configuration for old and new kernels?
Building from source. The .config files used started identical, but
looks like things changed in the Kconfig files which caused 4 items to
switch from 'm' to 'y' (all networking, which shouldn't cause the
observed bug). There were also some patches derived from OpenWRT's
patches, but those did not change at all.
> > > > Doing a double-kexec does work around the issue, but it means I need to
> > > > hold onto that one magic kernel for the moment...
> > > >
> > > > In other news, it appears sometime between 3.3 and 3.10 there started
> > > > being a requirement for GCC 4.8 on mipsel.
> > > Packages in jessie must be buildable using compiler versions in jessie.
> > > That means either gcc-4.8 or gcc-4.9.
> > linux-source-3.16 is available as a backport to wheezy, which does not
> > feature gcc-4.8.
>
> That in no way contradicts what I said. :-) ??When I backport the linux
> source package from jessie to wheezy I change it to use gcc-4.6.
>
> But the linux-source-X.Y packages (which are a different thing to the
> linux source package!) don't specify any particular compiler version.
> You can choose that with the CC variable; otherwise the default
> compiler (specified by the gcc package) will be used.
For this particular mipsel device I was unable to kexec the kernel unless
it was built with GCC-4.8. If the kernel was built with GCC-4.7 or
earlier, I got symptoms identical to the above, messages from the old
kernel on the console serial port that it was going away and kexec'd
kernel never output any messages. I could believe this is a funky
compiler issue.
--
(\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/)
\BS ( | EHeM+sigmsg@m5p.com PGP 87145445 | ) /
\_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
Reply to: