[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#820567: marked as done (kexec on mipsel partially broken between ckt20 and ckt25)

Your message dated Mon, 11 Apr 2016 12:26:40 +0100
with message-id <1460374000.25201.18.camel@decadent.org.uk>
and subject line Re: Bug#820567: kexec on mipsel partially broken between ckt20 and ckt25
has caused the Debian Bug report #820567,
regarding kexec on mipsel partially broken between ckt20 and ckt25
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
820567: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820567
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: linux-source-3.16
Version: 3.16.7-ckt25-1~bpo70+1

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.

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.


-- 
(\___(\___(\______          --=> 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

--- End Message ---
--- Begin Message --- 
On Sun, 2016-04-10 at 22:49 -0700, Elliott Mitchell wrote:
> On Mon, Apr 11, 2016 at 01:34:56AM +0100, Ben Hutchings wrote:
[...]
> > Could it be the kernel image is close to a critical size limit? ??The
> > kernel typically gets slightly larger with each stable update. ??Does
> > gcc 4.8 generate a smaller or larger kernel image than older versions?
> You win one and lose one.  I tracked down the configuration option that
> managed to switch from "y" to "n" (seems my base config had it as "y",
> but other options interfered, now it is "m"), that shrank the kernel by
> 40KB and the resultant kernel was successfully loaded by the 3.3 kernel.
> 
> The kernel built with GCC 4.4 was about 2% larger than the GCC 4.8 build,
> while a GCC 4.6 build was less than 1% smaller than the GCC 4.8 build.
> Neither of these kernels was able to successfully start when kexec'd by
> a 3.16 kernel (which *was* able to start the bigger kernel).
> 
> 
> So this solves the problem this bug was about, it was a size issue.  :-(
[...]

As this is a custom kernel configuration, we cannot control the size,
so I think there's nothing for us to do here.

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.

Attachment: signature.asc
Description: This is a digitally signed message part


--- End Message ---
Reply to: