Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #57726 > unrolled thread

armel/marvell kernel size

Back to article view | Back to linux.debian.kernel

Contents

  armel/marvell kernel size Ben Hutchings <ben@decadent.org.uk> - 2017-05-04 00:20 +0200
    Re: armel/marvell kernel size Roger Shimizu <rogershimizu@gmail.com> - 2017-05-06 07:50 +0200
      Re: armel/marvell kernel size Martin Michlmayr <tbm@cyrius.com> - 2017-05-08 16:10 +0200
        Re: armel/marvell kernel size Roger Shimizu <rogershimizu@gmail.com> - 2017-05-08 16:30 +0200
    Re: armel/marvell kernel size Ben Hutchings <ben@decadent.org.uk> - 2017-07-22 01:50 +0200
      Re: armel/marvell kernel size Roger Shimizu <rogershimizu@gmail.com> - 2017-07-22 17:40 +0200
        Re: armel/marvell kernel size Ben Hutchings <ben@decadent.org.uk> - 2017-07-22 18:30 +0200
      Re: armel/marvell kernel size Roger Shimizu <rogershimizu@gmail.com> - 2017-07-30 20:30 +0200
        Re: armel/marvell kernel size Ben Hutchings <ben@decadent.org.uk> - 2017-07-30 21:40 +0200
        Re: armel/marvell kernel size Ian Campbell <ijc@hellion.org.uk> - 2017-07-31 00:50 +0200
          Re: armel/marvell kernel size Roger Shimizu <rogershimizu@gmail.com> - 2017-07-31 02:30 +0200
        Re: armel/marvell kernel size Roger Shimizu <rogershimizu@gmail.com> - 2017-07-31 17:10 +0200
          Re: armel/marvell kernel size Roger Shimizu <rogershimizu@gmail.com> - 2017-08-17 18:20 +0200
          Bug#870185: armel/marvell kernel size Roger Shimizu <rogershimizu@gmail.com> - 2017-08-19 06:10 +0200
            Bug#870185: armel/marvell kernel size Ian Campbell <ijc@debian.org> - 2017-08-19 18:00 +0200
              Bug#870185: armel/marvell kernel size Roger Shimizu <rogershimizu@gmail.com> - 2017-08-19 19:40 +0200
                Bug#870185: armel/marvell kernel size Ben Hutchings <ben@decadent.org.uk> - 2017-08-20 00:00 +0200
                  Bug#870185: armel/marvell kernel size Roger Shimizu <rogershimizu@gmail.com> - 2017-08-20 14:30 +0200
                    Bug#870185: armel/marvell kernel size Ben Hutchings <ben@decadent.org.uk> - 2017-08-20 17:50 +0200
                      Bug#870185: armel/marvell kernel size Roger Shimizu <rogershimizu@gmail.com> - 2017-08-21 02:40 +0200
                        Bug#870185: armel/marvell kernel size Roger Shimizu <rogershimizu@gmail.com> - 2017-08-21 18:30 +0200
                          Bug#870185: armel/marvell kernel size Ben Hutchings <ben@decadent.org.uk> - 2017-08-21 20:00 +0200
                            Bug#870185: armel/marvell kernel size Roger Shimizu <rogershimizu@gmail.com> - 2017-08-26 18:40 +0200
                              Bug#870185: armel/marvell kernel size Roger Shimizu <rogershimizu@gmail.com> - 2017-08-26 18:40 +0200
                                Bug#870185: armel/marvell kernel size Roger Shimizu <rogershimizu@gmail.com> - 2017-08-27 17:40 +0200
                                  Bug#870185: armel/marvell kernel size Ben Hutchings <ben@decadent.org.uk> - 2017-08-27 17:40 +0200

Page 1 of 2  [1] 2  Next page →

#57726 — armel/marvell kernel size

[Multipart message — attachments visible in raw view] — view raw

linux 4.11-1~exp1 FTBFS on armel.  I spent a little while modularising
some things that were unnecessarily built-in, but the image size will
still be very close to the current limit of 2 MiB.  If it grows beyond
this we'll lose support for many QNAP models.

It should be possible to reduce the image size quite a bit by changing
NAND drivers to modules.  I don't know if initramfs-tools is smart
enough to include these drivers in the initramfs where needed.  It
would certainly be necessary to add those drivers to the mtd-modules
udeb.

It may also be possible to reduce the image size by modularising more
cryptographic stuff.  The big piece there is cryptomgr
(CONFIG_CRYPTO_MANAGER2), which is directly or indirectly selected by
most other cryptographic options.  So this might be impossible.  It
also might require changes to cryptsetup to get the right modules
included in the initramfs.

I'm going to leave further decisions on the size limit and
configuration to you.  If armel/marvell breaks again and stays broken
then I'm going to have to disable it.

Ben.

-- 
Ben Hutchings
friends: People who know you well, but like you anyway.

[toc] | [next] | [standalone]

#57746

[Multipart message — attachments visible in raw view] — view raw

[ CC: Martin ]

Dear Ben,

Thanks for your effort to support armel/marvell!

On Wed, 03 May 2017 23:12:40 +0100
Ben Hutchings <ben@decadent.org.uk> wrote:

> linux 4.11-1~exp1 FTBFS on armel.  I spent a little while modularising
> some things that were unnecessarily built-in, but the image size will
> still be very close to the current limit of 2 MiB.  If it grows beyond
> this we'll lose support for many QNAP models.

I'll try to take care of armel/marvell.
But I don't have QNAP device personally.
I have a few Buffalo Linkstation devices that use /dev/sda1 as /boot,
so they don't have the 2MB limitation which QNAP devices have.

I'll make changes when necessary, and ask Martin and/or other QNAP users
to test.

> It should be possible to reduce the image size quite a bit by changing
> NAND drivers to modules.  I don't know if initramfs-tools is smart
> enough to include these drivers in the initramfs where needed.  It
> would certainly be necessary to add those drivers to the mtd-modules
> udeb.
> 
> It may also be possible to reduce the image size by modularising more
> cryptographic stuff.  The big piece there is cryptomgr
> (CONFIG_CRYPTO_MANAGER2), which is directly or indirectly selected by
> most other cryptographic options.  So this might be impossible.  It
> also might require changes to cryptsetup to get the right modules
> included in the initramfs.
> 
> I'm going to leave further decisions on the size limit and
> configuration to you.  If armel/marvell breaks again and stays broken
> then I'm going to have to disable it.

Thanks for the advices!
I'll chase those possibilities (maybe after stretch released).
If I break something, kindly let me know.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

[toc] | [prev] | [next] | [standalone]

#57753

* Roger Shimizu <rogershimizu@gmail.com> [2017-05-06 14:45]:
> I'll try to take care of armel/marvell.

I thought the plan was to drop the whole armel architecture after
stretch anyway.

Maybe we should start that conversation on debian-arm again at some
point to see what the current consensus is.

-- 
Martin Michlmayr
http://www.cyrius.com/

[toc] | [prev] | [next] | [standalone]

#57754

[Multipart message — attachments visible in raw view] — view raw

On Mon, 8 May 2017 16:03:50 +0200
Martin Michlmayr <tbm@cyrius.com> wrote:

> * Roger Shimizu <rogershimizu@gmail.com> [2017-05-06 14:45]:
> > I'll try to take care of armel/marvell.
> 
> I thought the plan was to drop the whole armel architecture after
> stretch anyway.
> 
> Maybe we should start that conversation on debian-arm again at some
> point to see what the current consensus is.

I started a thread on whether to remove armel after stretch last
December [0]. And Steve agreed that he'll not push to remove armel
after stretch [1].

With the toolchain issues resolved in stretch (toolchain issues
mentioned here [2]), I think the main work is to keep the kernel size
and initrd size (including initrd for d-i) within QNAP's limitation.
Maybe we have to remove QNAP support some time before buster, it's
still able to support other armel with /boot mounting in HDD)

[0] https://lists.debian.org/debian-devel/2016/12/msg00135.html
[1] https://lists.debian.org/debian-devel/2016/12/msg00329.html
[2] https://lists.debian.org/debian-devel/2016/12/msg00143.html

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

[toc] | [prev] | [next] | [standalone]

#58480

[Multipart message — attachments visible in raw view] — view raw

On Wed, 2017-05-03 at 23:12 +0100, Ben Hutchings wrote:
> linux 4.11-1~exp1 FTBFS on armel.  I spent a little while modularising
> some things that were unnecessarily built-in, but the image size will
> still be very close to the current limit of 2 MiB.  If it grows beyond
> this we'll lose support for many QNAP models.

It's now (with 4.12.2-1~exp1) over 2 MiB; please look at this.

Ben.

> It should be possible to reduce the image size quite a bit by changing
> NAND drivers to modules.  I don't know if initramfs-tools is smart
> enough to include these drivers in the initramfs where needed.  It
> would certainly be necessary to add those drivers to the mtd-modules
> udeb.
> 
> It may also be possible to reduce the image size by modularising more
> cryptographic stuff.  The big piece there is cryptomgr
> (CONFIG_CRYPTO_MANAGER2), which is directly or indirectly selected by
> most other cryptographic options.  So this might be impossible.  It
> also might require changes to cryptsetup to get the right modules
> included in the initramfs.
> 
> I'm going to leave further decisions on the size limit and
> configuration to you.  If armel/marvell breaks again and stays broken
> then I'm going to have to disable it.
> 
> Ben.
> 
-- 
Ben Hutchings
All extremists should be taken out and shot.

[toc] | [prev] | [next] | [standalone]

#58481

On Sat, Jul 22, 2017 at 8:40 AM, Ben Hutchings <ben@decadent.org.uk> wrote:
>
> On Wed, 2017-05-03 at 23:12 +0100, Ben Hutchings wrote:
> > linux 4.11-1~exp1 FTBFS on armel.  I spent a little while modularising
> > some things that were unnecessarily built-in, but the image size will
> > still be very close to the current limit of 2 MiB.  If it grows beyond
> > this we'll lose support for many QNAP models.
>
> It's now (with 4.12.2-1~exp1) over 2 MiB; please look at this.

OK.
BTW. When do you plan to upload 4.12 series kernel to unstable?

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

[toc] | [prev] | [next] | [standalone]

#58482

[Multipart message — attachments visible in raw view] — view raw

On Sun, 2017-07-23 at 00:14 +0900, Roger Shimizu wrote:
> On Sat, Jul 22, 2017 at 8:40 AM, Ben Hutchings <ben@decadent.org.uk>
> wrote:
> > 
> > On Wed, 2017-05-03 at 23:12 +0100, Ben Hutchings wrote:
> > > linux 4.11-1~exp1 FTBFS on armel.  I spent a little while
> > > modularising
> > > some things that were unnecessarily built-in, but the image size
> > > will
> > > still be very close to the current limit of 2 MiB.  If it grows
> > > beyond
> > > this we'll lose support for many QNAP models.
> > 
> > It's now (with 4.12.2-1~exp1) over 2 MiB; please look at this.
> 
> OK.
> BTW. When do you plan to upload 4.12 series kernel to unstable?

Some time in the next week.

Ben.

-- 
Ben Hutchings
All extremists should be taken out and shot.

[toc] | [prev] | [next] | [standalone]

#58554

On Sat, Jul 22, 2017 at 8:40 AM, Ben Hutchings <ben@decadent.org.uk> wrote:
> On Wed, 2017-05-03 at 23:12 +0100, Ben Hutchings wrote:
>> linux 4.11-1~exp1 FTBFS on armel.  I spent a little while modularising
>> some things that were unnecessarily built-in, but the image size will
>> still be very close to the current limit of 2 MiB.  If it grows beyond
>> this we'll lose support for many QNAP models.
>
> It's now (with 4.12.2-1~exp1) over 2 MiB; please look at this.

While I'm still working on this, but I find the latest kernel in
archive, 4.11.11-1+b1, fails to boot on my kirkwood based Linkstation.
I tried netconsole, but don't get any log. (netconsole outputs fine on
working kernels, such as 4.9 and 4.10 series.)
And I trace to latest working kernel is 4.10.7-1~exp1.

4.11-1_exp[12] FTBFS on armel, and 4.11.3-1_exp1 doesn't boot.

I checked d-kernel and d-arm list, but didn't find similar issue.
Do you have any clue on this? Thanks!

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

[toc] | [prev] | [next] | [standalone]

#58556

[Multipart message — attachments visible in raw view] — view raw

On Mon, 2017-07-31 at 03:05 +0900, Roger Shimizu wrote:
> > On Sat, Jul 22, 2017 at 8:40 AM, Ben Hutchings <ben@decadent.org.uk> wrote:
> > On Wed, 2017-05-03 at 23:12 +0100, Ben Hutchings wrote:
> > > linux 4.11-1~exp1 FTBFS on armel.  I spent a little while modularising
> > > some things that were unnecessarily built-in, but the image size will
> > > still be very close to the current limit of 2 MiB.  If it grows beyond
> > > this we'll lose support for many QNAP models.
> > 
> > It's now (with 4.12.2-1~exp1) over 2 MiB; please look at this.
> 
> While I'm still working on this, but I find the latest kernel in
> archive, 4.11.11-1+b1, fails to boot on my kirkwood based Linkstation.
> I tried netconsole, but don't get any log. (netconsole outputs fine on
> working kernels, such as 4.9 and 4.10 series.)
> And I trace to latest working kernel is 4.10.7-1~exp1.
> 
> 4.11-1_exp[12] FTBFS on armel, and 4.11.3-1_exp1 doesn't boot.
> 
> I checked d-kernel and d-arm list, but didn't find similar issue.
> Do you have any clue on this? Thanks!

No idea, sorry.

Ben.

-- 
Ben Hutchings
Knowledge is power.  France is bacon.

[toc] | [prev] | [next] | [standalone]

#58558

On 30 July 2017 19:05:18 BST, Roger Shimizu <rogershimizu@gmail.com> wrote:
>On Sat, Jul 22, 2017 at 8:40 AM, Ben Hutchings <ben@decadent.org.uk>
>wrote:
>> On Wed, 2017-05-03 at 23:12 +0100, Ben Hutchings wrote:
>>> linux 4.11-1~exp1 FTBFS on armel.  I spent a little while
>modularising
>>> some things that were unnecessarily built-in, but the image size
>will
>>> still be very close to the current limit of 2 MiB.  If it grows
>beyond
>>> this we'll lose support for many QNAP models.
>>
>> It's now (with 4.12.2-1~exp1) over 2 MiB; please look at this.
>
>While I'm still working on this, but I find the latest kernel in
>archive, 4.11.11-1+b1, fails to boot on my kirkwood based Linkstation.
>I tried netconsole, but don't get any log. (netconsole outputs fine on
>working kernels, such as 4.9 and 4.10 series.)
>And I trace to latest working kernel is 4.10.7-1~exp1.
>
>4.11-1_exp[12] FTBFS on armel, and 4.11.3-1_exp1 doesn't boot.
>
>I checked d-kernel and d-arm list, but didn't find similar issue.
>Do you have any clue on this? Thanks!

I found that with 4.11 the initrd was too big for my ts41x. Could it be that?

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[toc] | [prev] | [next] | [standalone]

#58559

On Mon, Jul 31, 2017 at 7:16 AM, Ian Campbell <ijc@hellion.org.uk> wrote:
>
> I found that with 4.11 the initrd was too big for my ts41x. Could it be that?

Thanks for providing the info!

Stock initrd of Linkstation is 9MB, and now Debian's initrd is just
4+MB (MODULE=dep, compressed by gzip).
So I don't think it's a problem for Linkstation case.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

[toc] | [prev] | [next] | [standalone]

#58563

On Mon, Jul 31, 2017 at 3:05 AM, Roger Shimizu <rogershimizu@gmail.com> wrote:
>
> While I'm still working on this, but I find the latest kernel in
> archive, 4.11.11-1+b1, fails to boot on my kirkwood based Linkstation.
> I tried netconsole, but don't get any log. (netconsole outputs fine on
> working kernels, such as 4.9 and 4.10 series.)
> And I trace to latest working kernel is 4.10.7-1~exp1.
>
> 4.11-1_exp[12] FTBFS on armel, and 4.11.3-1_exp1 doesn't boot.
>
> I checked d-kernel and d-arm list, but didn't find similar issue.
> Do you have any clue on this? Thanks!

I think my problem is very likely the same as:
 - https://bugs.debian.org/870185

And I tried Ben's recommendation to make armel kernel smaller,
which I pushed to branch rosh/strip_armel on alioth, confirmed it worked
well for 4.10.7-1~exp1 (by cherry-pick) on my kirkwood based Linkstation.

I know it's better to confirm the d-i part, but I don't have much time before
debconf..

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

[toc] | [prev] | [next] | [standalone]

#58693

On Mon, Jul 31, 2017 at 11:43 PM, Roger Shimizu <rogershimizu@gmail.com> wrote:
> And I tried Ben's recommendation to make armel kernel smaller,
> which I pushed to branch rosh/strip_armel on alioth, confirmed it worked
> well for 4.10.7-1~exp1 (by cherry-pick) on my kirkwood based Linkstation.

I already noticed that the above attempt fails for armel, again, for
latest 3.13 kernel in experimental.
I'll try to fix it this weekend.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

[toc] | [prev] | [next] | [standalone]

#58700 — Bug#870185: armel/marvell kernel size

On Mon, Jul 31, 2017 at 11:43 PM, Roger Shimizu <rogershimizu@gmail.com> wrote:
> On Mon, Jul 31, 2017 at 3:05 AM, Roger Shimizu <rogershimizu@gmail.com> wrote:
>>
>> While I'm still working on this, but I find the latest kernel in
>> archive, 4.11.11-1+b1, fails to boot on my kirkwood based Linkstation.
>> I tried netconsole, but don't get any log. (netconsole outputs fine on
>> working kernels, such as 4.9 and 4.10 series.)
>> And I trace to latest working kernel is 4.10.7-1~exp1.
>>
>> 4.11-1_exp[12] FTBFS on armel, and 4.11.3-1_exp1 doesn't boot.
>>
>> I checked d-kernel and d-arm list, but didn't find similar issue.
>> Do you have any clue on this? Thanks!
>
> I think my problem is very likely the same as:
>  - https://bugs.debian.org/870185
>
> And I tried Ben's recommendation to make armel kernel smaller,
> which I pushed to branch rosh/strip_armel on alioth, confirmed it worked
> well for 4.10.7-1~exp1 (by cherry-pick) on my kirkwood based Linkstation.

I find some new clue about kernel size issue for armel.
vmlinuz installed under /boot is compressed. It can be decompressed by
"scripts/extract-vmlinux" script under linux git repo. But for armel,
it need at patch I posted:
 - https://patchwork.kernel.org/patch/8120831/

After I decompress the kernel images, I find the size for 4.11
increased significantly:

====
$ ~/linux/scripts/extract-vmlinux /boot/vmlinuz-4.9.0-3-marvell >
~/vmlinuz-4.9.0-3-marvell.extracted
$ ~/linux/scripts/extract-vmlinux /boot/vmlinuz-4.10.0-trunk-marvell >
~/vmlinuz-4.10.0-trunk-marvell.extracted
$ ~/linux/scripts/extract-vmlinux /boot/vmlinuz-4.11.0-0.bpo.1-marvell
> ~/vmlinuz-4.11.0-0.bpo.1-marvell.extracted

$ ls -l ~/vmlinuz-*
-rw-r--r-- 1 rosh rosh 5782024 Aug 19 12:35
vmlinuz-4.10.0-trunk-marvell.extracted
-rw-r--r-- 1 rosh rosh 8763712 Aug 19 12:36
vmlinuz-4.11.0-0.bpo.1-marvell.extracted
-rw-r--r-- 1 rosh rosh 5844072 Aug 19 12:35 vmlinuz-4.9.0-3-marvell.extracted
====

I know for bug #870185, Robert fixed his device by modify uboot
params, but I guess it's still possible to keep uboot params and only
change the boot addresses of kernel/initrd in flash-kernel db file.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

[toc] | [prev] | [next] | [standalone]

#58702 — Bug#870185: armel/marvell kernel size

On Sat, 2017-08-19 at 12:57 +0900, Roger Shimizu wrote:
> I know for bug #870185, Robert fixed his device by modify uboot
> params, but I guess it's still possible to keep uboot params and only
> change the boot addresses of kernel/initrd in flash-kernel db file.

In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870185#35 I
concluded it wasn't, perhaps I'm wrong though.

Can someone confirm whether the issue is that the u-boot load addresses
 for kernel and initrd are conflicting or if it is the kernel's
target/decompression address and u-boot's initrd address which are
conflicting? The symptoms seem to suggest the kernel is being
decompressed over the initrd.

Since we don't want to change the u-boot we can't easily influence the
initrd address (since it doesn't use a u-boot header on this platform).
So it would seem the only possibility (other than shrinking the kernel)
would be to change the address at which it decompresses itself so it
doesn't conflict with the initrd.

Not sure how hard that would be -- it might be as simple as tweaking a
constant in the source or a Kconfig option, but I suspect it might
involve changing early boot assembly...

Ian.

[toc] | [prev] | [next] | [standalone]

#58704 — Bug#870185: armel/marvell kernel size

On Sun, Aug 20, 2017 at 12:55 AM, Ian Campbell <ijc@debian.org> wrote:
> On Sat, 2017-08-19 at 12:57 +0900, Roger Shimizu wrote:
>> I know for bug #870185, Robert fixed his device by modify uboot
>> params, but I guess it's still possible to keep uboot params and only
>> change the boot addresses of kernel/initrd in flash-kernel db file.
>
> In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870185#35 I
> concluded it wasn't, perhaps I'm wrong though.

You may read my previous research:
- https://bugs.debian.org/809476#49

> Can someone confirm whether the issue is that the u-boot load addresses
>  for kernel and initrd are conflicting or if it is the kernel's
> target/decompression address and u-boot's initrd address which are
> conflicting? The symptoms seem to suggest the kernel is being
> decompressed over the initrd.

The real problem is kernel size (after decompression) increased from
5MB to 8MB. (detail is in my previous post)
This looks like a bug, since usually kernel size grows gradually, not
in +3MB way this time.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

[toc] | [prev] | [next] | [standalone]

#58710 — Bug#870185: armel/marvell kernel size

[Multipart message — attachments visible in raw view] — view raw

On Sun, 2017-08-20 at 02:35 +0900, Roger Shimizu wrote:
> On Sun, Aug 20, 2017 at 12:55 AM, Ian Campbell <ijc@debian.org>
> wrote:
> > On Sat, 2017-08-19 at 12:57 +0900, Roger Shimizu wrote:
> > > I know for bug #870185, Robert fixed his device by modify uboot
> > > params, but I guess it's still possible to keep uboot params and
> > > only
> > > change the boot addresses of kernel/initrd in flash-kernel db
> > > file.
> > 
> > In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870185#35 I
> > concluded it wasn't, perhaps I'm wrong though.
> 
> You may read my previous research:
> - https://bugs.debian.org/809476#49
> 
> > Can someone confirm whether the issue is that the u-boot load
> > addresses
> >  for kernel and initrd are conflicting or if it is the kernel's
> > target/decompression address and u-boot's initrd address which are
> > conflicting? The symptoms seem to suggest the kernel is being
> > decompressed over the initrd.
> 
> The real problem is kernel size (after decompression) increased from
> 5MB to 8MB. (detail is in my previous post)
> This looks like a bug, since usually kernel size grows gradually, not
> in +3MB way this time.

Some things to check:

- If you build 4.10 with the config used for 4.11 (whichever is the
first larger one), is the size 5 MB or 8 MB?

- If not, try bisecting the upstream source to find a jump in size.

Ben.

-- 
Ben Hutchings
The generation of random numbers is too important to be left to chance.
                                                       - Robert Coveyou

[toc] | [prev] | [next] | [standalone]

#58716 — Bug#870185: armel/marvell kernel size

On Sun, Aug 20, 2017 at 6:54 AM, Ben Hutchings <ben@decadent.org.uk> wrote:
> On Sun, 2017-08-20 at 02:35 +0900, Roger Shimizu wrote:
>>
>> The real problem is kernel size (after decompression) increased from
>> 5MB to 8MB. (detail is in my previous post)
>> This looks like a bug, since usually kernel size grows gradually, not
>> in +3MB way this time.
>
> Some things to check:
>
> - If you build 4.10 with the config used for 4.11 (whichever is the
> first larger one), is the size 5 MB or 8 MB?

I build vanilla kernel with debian config, and here's the result.
(images are under arch/arm/boot/)

linux_4.10.7 with debian 4.10.7 config
-rwxr-xr-x 1 rosh rosh 5757504 Aug 20 06:40 Image
-rwxr-xr-x 1 rosh rosh 2012496 Aug 20 06:40 zImage

linux_4.11.6 with debian 4.11.6 config
-rwxr-xr-x 1 rosh rosh 8763712 Aug 20 07:03 Image
-rwxr-xr-x 1 rosh rosh 2064576 Aug 20 07:03 zImage

linux_4.11.6 with debian 4.10.7 config
-rwxr-xr-x 1 rosh rosh 5891216 Aug 20 07:43 Image
-rwxr-xr-x 1 rosh rosh 2049216 Aug 20 07:43 zImage

linux_4.10.7 with debian 4.11.6 config
-rwxr-xr-x 1 rosh rosh 5811408 Aug 20 07:56 Image
-rwxr-xr-x 1 rosh rosh 2032704 Aug 20 07:56 zImage

So it seems the problem is pointing to config changes since 4.11.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

[toc] | [prev] | [next] | [standalone]

#58722 — Bug#870185: armel/marvell kernel size

[Multipart message — attachments visible in raw view] — view raw

On Sun, 2017-08-20 at 21:16 +0900, Roger Shimizu wrote:
> On Sun, Aug 20, 2017 at 6:54 AM, Ben Hutchings <ben@decadent.org.uk>
> wrote:
> > On Sun, 2017-08-20 at 02:35 +0900, Roger Shimizu wrote:
> > > 
> > > The real problem is kernel size (after decompression) increased
> > > from
> > > 5MB to 8MB. (detail is in my previous post)
> > > This looks like a bug, since usually kernel size grows gradually,
> > > not
> > > in +3MB way this time.
> > 
> > Some things to check:
> > 
> > - If you build 4.10 with the config used for 4.11 (whichever is the
> > first larger one), is the size 5 MB or 8 MB?
> 
> I build vanilla kernel with debian config, and here's the result.
> (images are under arch/arm/boot/)
> 
> linux_4.10.7 with debian 4.10.7 config
> -rwxr-xr-x 1 rosh rosh 5757504 Aug 20 06:40 Image
> -rwxr-xr-x 1 rosh rosh 2012496 Aug 20 06:40 zImage
> 
> linux_4.11.6 with debian 4.11.6 config
> -rwxr-xr-x 1 rosh rosh 8763712 Aug 20 07:03 Image
> -rwxr-xr-x 1 rosh rosh 2064576 Aug 20 07:03 zImage
> 
> linux_4.11.6 with debian 4.10.7 config
> -rwxr-xr-x 1 rosh rosh 5891216 Aug 20 07:43 Image
> -rwxr-xr-x 1 rosh rosh 2049216 Aug 20 07:43 zImage
> 
> linux_4.10.7 with debian 4.11.6 config
> -rwxr-xr-x 1 rosh rosh 5811408 Aug 20 07:56 Image
> -rwxr-xr-x 1 rosh rosh 2032704 Aug 20 07:56 zImage
> 
> So it seems the problem is pointing to config changes since 4.11.

OK, then try using 4.11.6 source and bisecting the Debian config
changes.

Ben.

-- 
Ben Hutchings
It is a miracle that curiosity survives formal education. - Albert
Einstein

[toc] | [prev] | [next] | [standalone]

#58728 — Bug#870185: armel/marvell kernel size

On Mon, Aug 21, 2017 at 12:43 AM, Ben Hutchings <ben@decadent.org.uk> wrote:
>
> OK, then try using 4.11.6 source and bisecting the Debian config
> changes.

Result:
0905519af414d339f615d7aac974f9a9163cdbd3 is the first bad commit

Here's the detailed log.

$ git bisect log
git bisect start
# good: [327c328b5435d93c2d3294059882629a6f8f1861] Update to 4.11-rc7
(and credit Lukas for his previous work)
git bisect good 327c328b5435d93c2d3294059882629a6f8f1861
# bad: [aca58f89537f4c470cc1e9102c1249e39a4b13a3] Prepare to release
linux (4.11.3-1~exp1).
git bisect bad aca58f89537f4c470cc1e9102c1249e39a4b13a3
# good: [3f68b53e2c3d425af23d0fbc33ef1e5f932484ab] usbip: Enable
USBIP_VUDC as module
git bisect good 3f68b53e2c3d425af23d0fbc33ef1e5f932484ab
# bad: [0a348a06ca2392fe337580ba007f325bdb111ff1] [armel] udeb: Add
af_packet. firmware_class, nls_base to kernel-image (fixes FTBFS)
git bisect bad 0a348a06ca2392fe337580ba007f325bdb111ff1
# good: [472b038c1a71a837c1cd30d49f6cda385e9dd540] udeb: Move mfd-core
to kernel-image, as both input-modules and mmc-modules need it
git bisect good 472b038c1a71a837c1cd30d49f6cda385e9dd540
# bad: [2d277e1fa20d2fe1fc5414f3806fded57bf9200b] Update to 4.11
git bisect bad 2d277e1fa20d2fe1fc5414f3806fded57bf9200b
# bad: [0905519af414d339f615d7aac974f9a9163cdbd3] Clean up kconfig
using kconfigeditor2
git bisect bad 0905519af414d339f615d7aac974f9a9163cdbd3
# good: [0e0b29ad5ab36d7268f8a50fb5a5c90cea4186c9] [arm64,x86] Replace
securelevel patch set with lockdown patch set
git bisect good 0e0b29ad5ab36d7268f8a50fb5a5c90cea4186c9
# good: [259372e240d0021eb2acdc98bd61b6adb84d645e] [x86] Make
hyperv-modules depends on nic-shared-modules
git bisect good 259372e240d0021eb2acdc98bd61b6adb84d645e
# first bad commit: [0905519af414d339f615d7aac974f9a9163cdbd3] Clean
up kconfig using kconfigeditor2

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.kernel

csiph-web