Roger,
Since we moved from Linux 5.0 to 5.2 the kernel size has increased
again and has broken the 2 MiB limit for armel/marvell:
https://buildd.debian.org/status/fetch.php?pkg=linux&arch=armel&ver=5.2.6-1&stamp=1565084795&raw=0
As there is an important security update in 5.2.7 that I want to get
Dear Ian, Ben,
On Sun, Apr 15, 2018 at 9:50 PM, Ben Hutchings wrote:
> On Sun, 2018-04-15 at 08:16 +0100, Ian Campbell wrote:
>> On Sun, 2018-04-15 at 00:08 +0100, Ben Hutchings wrote:
>> > > For the lzo_decompress ones I think you need to add it to
>> > > installer/modules/lzo-modules and perhap
On Sun, Apr 8, 2018 at 5:47 PM, Ben Hutchings wrote:
> On Sat, 2018-04-07 at 23:38 +0900, Roger Shimizu wrote:
>> On Sat, Apr 7, 2018 at 11:16 PM, Roger Shimizu
>> wrote:
>> > Dear kernel folks,
>> >
>> > After all kinda tests recently, together with the patch from Leigh
>> > Brown (CC-ed) that
On Sat, Apr 7, 2018 at 11:16 PM, Roger Shimizu wrote:
> Dear kernel folks,
>
> After all kinda tests recently, together with the patch from Leigh
> Brown (CC-ed) that disabled VT, finally the armel/marvell can be
> reduced under 2MB again, without introducing a new flavour.
Sorry, I forgot to men
Dear Rogério,
I'll reply to you later, in a separate email.
Dear kernel folks,
After all kinda tests recently, together with the patch from Leigh
Brown (CC-ed) that disabled VT, finally the armel/marvell can be
reduced under 2MB again, without introducing a new flavour.
So I already pushed the
Dear Roger, Ben and others.
On Sun, Apr 1, 2018 at 10:25 AM, Roger Shimizu wrote:
> On Wed, Jan 24, 2018 at 3:30 AM, Ben Hutchings wrote:
>> On Mon, 2018-01-22 at 22:38 +0900, Roger Shimizu wrote:
>> There's an upstream change in cfg80211 that enables direct-loading of
>> wireless rules, which r
On Mar 28, 2018, at 2:22 AM, Rick Thomas wrote:
>> What filesystems do you use? Do you use any (para)virtualization? What
>> about addon hardware that you have? Any USB dongles? Anything that you
>> can think of? Sound?
>>
>> Do you use NFS? (I do) What kind of compressed ramdisk do you use? Th
Dear Ben, and other arm/kernel folks,
On Wed, Jan 24, 2018 at 3:30 AM, Ben Hutchings wrote:
> On Mon, 2018-01-22 at 22:38 +0900, Roger Shimizu wrote:
>
> There's an upstream change in cfg80211 that enables direct-loading of
> wireless rules, which requires public key crypto in the kernel. There
Hello guys,
I believe the problem we are facing on Kirkwood with stretch is the same I
had with iop32 and other folks with ixp4xx.
As the support for iop32 on Wheezy is under EOL, do we have any hopes to
solve the kernel size issue common for all this architectures or it's time
to replace our nas?
On Mar 27, 2018, at 2:08 PM, Rogério Brito wrote:
> On 2018-03-27 17:29, Rick Thomas wrote:
>> On Mar 27, 2018, at 1:04 PM, Rogério Brito wrote:
>>> As a related subject, I could compile a more stripped down version of
>>> the armel kernel, put it for people to download and ask people to
>>> co
On Wed, Mar 28, 2018 at 3:21 AM, W. Martin Borgert wrote:
> Quoting Ben Hutchings:
>>
>> Still, as armel will not be a release architecture any more, I suppose
>> it can diverge further from the normal configuration.
>
> I didn't know, that this already has been decided.
> Could you point to the em
>> I can answer this part: yes, you can definitely put an Intel wifi card
>> in the mini-pcie slot of an ARM box.
> This means that, in principle, we should enable many modules more to get
> as full support as desired in Debian on each and every arch...
My point wasn't just that it's technically p
On 2018-03-27 17:29, Rick Thomas wrote:
> On Mar 27, 2018, at 1:04 PM, Rogério Brito wrote:
>> As a related subject, I could compile a more stripped down version of
>> the armel kernel, put it for people to download and ask people to
>> comment if it works for them, so that we can gauge what peopl
Hi, Ben and others following the discussion.
On 2018-03-27 16:01, Ben Hutchings wrote:
> On Tue, 2018-03-27 at 02:30 -0300, Rogério Brito wrote:
> [...]
I will see if all the modules make sense for an embedded system like this
and I will send a list of options for opinions by others...
>
On Mar 27, 2018, at 1:04 PM, Rogério Brito wrote:
> As a related subject, I could compile a more stripped down version of
> the armel kernel, put it for people to download and ask people to
> comment if it works for them, so that we can gauge what people actually
> need from such a kernel...
Ple
Hi,Stefan.
On 2018-03-27 09:34, Stefan Monnier wrote:
>> Similarly for wifi cards like those Intel ones like iwlwifi (which is
>> the one that I have in this Core 2 Duo here)...
>
> I can answer this part: yes, you can definitely put an Intel wifi card
> in the mini-pcie slot of an ARM box.
Yes,
Quoting Ben Hutchings :
Still, as armel will not be a release architecture any more, I suppose
it can diverge further from the normal configuration.
I didn't know, that this already has been decided.
Could you point to the emails about this? Thanks!
On Tue, 2018-03-27 at 21:21 +0200, W. Martin Borgert wrote:
> Quoting Ben Hutchings :
> > Still, as armel will not be a release architecture any more, I
> > suppose
> > it can diverge further from the normal configuration.
>
> I didn't know, that this already has been decided.
> Could you point to
On Tue, 2018-03-27 at 02:30 -0300, Rogério Brito wrote:
[...]
> > > I will see if all the modules make sense for an embedded system like this
> > > and I will send a list of options for opinions by others...
> >
> > [...]
> >
> > As I see it, the point of installing Debian on little NAS boxes is
Hi Ben and others.
On Fri, Mar 23, 2018 at 10:50 PM, Ben Hutchings wrote:
> On Fri, 2018-03-23 at 18:15 -0300, Rogério Brito wrote:
> [...]
> > HOLY MOLY! THIS THING IS SLOW on my Core 2 Duo notebook... Granted, I only
> > have 4 GB of RAM, but the amount of modules that it compiles is
> > HUGE..
On Fri, 2018-03-23 at 18:15 -0300, Rogério Brito wrote:
[...]
> HOLY MOLY! THIS THING IS SLOW on my Core 2 Duo notebook... Granted, I only
> have 4 GB of RAM, but the amount of modules that it compiles is
> HUGE... Quite different from a "regular" kernel that I used to compile...
Don't you have ac
On Thu, 2018-03-22 at 00:12 -0300, Rogério Brito wrote:
[...]
> If nobody is working on getting a new kernel working on armel, I would
> like to (at least, unsuccessfully) try to get it to compile.
>
> At worst, I believe, I can gain some knowledge and compare what I get from
> this armel kernel w
Dear Roger and other people!
On Thu, Mar 22, 2018 at 8:40 AM, Roger Shimizu wrote:
> Good to hear from you again!
Thank you very much. Glad to hear from you again, keeping the armel flame lit!
First of all, it seems weird that my previous message didn't get to
the lists. I find this very strang
Dear Rogério,
Good to hear from you again!
On Thu, Mar 22, 2018 at 12:12 PM, Rogério Brito wrote:
> Hi, all (and sorry for jumping in a bit late).
>
> On 2018-02-17 10:48, Salvatore Bonaccorso wrote:
>> On Tue, Jan 23, 2018 at 06:30:23PM +, Ben Hutchings wrote:
>>> There's an upstream change
[ CC tbm ]
On Sat, Feb 17, 2018 at 9:57 PM, Bastian Blank wrote:
> On Sat, Feb 17, 2018 at 01:48:51PM +0100, Salvatore Bonaccorso wrote:
>> Did you had a chance to look at Ben's suggestions or ideas?
>> We would like to ideally upload a 4.15.x based version to unstable
>> (currently imported 4.15
On Sat, Feb 17, 2018 at 01:48:51PM +0100, Salvatore Bonaccorso wrote:
> Did you had a chance to look at Ben's suggestions or ideas?
> We would like to ideally upload a 4.15.x based version to unstable
> (currently imported 4.15.4).
I would start with disabling it. The armel architecture (not armhf
Hi Roger,
On Tue, Jan 23, 2018 at 06:30:23PM +, Ben Hutchings wrote:
> On Mon, 2018-01-22 at 22:38 +0900, Roger Shimizu wrote:
> > Dear Ben,
> >
> > Thanks for keeping armel things rolling for a few releases!
> >
> > On Thu, Jan 18, 2018 at 1:22 PM, Ben Hutchings wrote:
> > > On Fri, 2017-1
Another possibility is to use LTO (Link-Time Optimisation):
https://lwn.net/SubscriberLink/744507/6489bc782122ca29/
However this is not yet supported in mainline, and it might require
more VM than is available on an armel buildd.
Ben.
--
Ben Hutchings
Unix is many things to many people,
but it'
On Mon, 2018-01-22 at 22:38 +0900, Roger Shimizu wrote:
> Dear Ben,
>
> Thanks for keeping armel things rolling for a few releases!
>
> On Thu, Jan 18, 2018 at 1:22 PM, Ben Hutchings wrote:
> > On Fri, 2017-10-20 at 15:07 +0100, Ben Hutchings wrote:
> > > Sadly, linux has again failed to build o
Dear Ben,
Thanks for keeping armel things rolling for a few releases!
On Thu, Jan 18, 2018 at 1:22 PM, Ben Hutchings wrote:
> On Fri, 2017-10-20 at 15:07 +0100, Ben Hutchings wrote:
>> Sadly, linux has again failed to build on armel in experimental due to
>> the image size growing too large.
>
>
On Fri, 2017-10-20 at 15:07 +0100, Ben Hutchings wrote:
> Sadly, linux has again failed to build on armel in experimental due to
> the image size growing too large.
It's happened again. The compressed image is 1% over the limit.
Ben.
--
Ben Hutchings
If at first you don't succeed, you're doing
On Fri, Oct 27, 2017 at 6:03 AM, Ben Hutchings wrote:
> On Tue, 2017-10-24 at 00:10 +0900, Roger Shimizu wrote:
>> Dear Ben,
>>
>> Thanks for the ping!
>>
>> On Fri, Oct 20, 2017 at 11:07 PM, Ben Hutchings wrote:
>> > Sadly, linux has again failed to build on armel in experimental due to
>> > the
On Tue, 2017-10-24 at 00:10 +0900, Roger Shimizu wrote:
> Dear Ben,
>
> Thanks for the ping!
>
> On Fri, Oct 20, 2017 at 11:07 PM, Ben Hutchings wrote:
> > Sadly, linux has again failed to build on armel in experimental due to
> > the image size growing too large.
>
> Yes, I noticed this armel
Dear Ben,
Thanks for the ping!
On Fri, Oct 20, 2017 at 11:07 PM, Ben Hutchings wrote:
> Sadly, linux has again failed to build on armel in experimental due to
> the image size growing too large.
Yes, I noticed this armel FTBFS issue.
However, the solution simple solution, you mentioned in previ
Sadly, linux has again failed to build on armel in experimental due to
the image size growing too large.
Ben.
--
Ben Hutchings
Make three consecutive correct guesses and you will be considered an
expert.
signature.asc
Description: This is a digitally signed message part
On Sun, Aug 27, 2017 at 1:31 AM, Roger Shimizu wrote:
> On Sun, Aug 27, 2017 at 1:27 AM, Roger Shimizu wrote:
>> On Tue, Aug 22, 2017 at 2:55 AM, Ben Hutchings wrote:
>>> For the size check, you're mostly duplicating the existing check_size()
>>> function. It would be preferable to have a singl
On Mon, 2017-08-28 at 00:34 +0900, Roger Shimizu wrote:
> On Sun, Aug 27, 2017 at 1:31 AM, Roger Shimizu wrote:
> > On Sun, Aug 27, 2017 at 1:27 AM, Roger Shimizu
> > wrote:
> > > On Tue, Aug 22, 2017 at 2:55 AM, Ben Hutchings
> > > wrote:
> > > > For the size check, you're mostly duplicating
On Sun, Aug 27, 2017 at 1:27 AM, Roger Shimizu wrote:
> On Tue, Aug 22, 2017 at 2:55 AM, Ben Hutchings wrote:
>> For the size check, you're mostly duplicating the existing check_size()
>> function. It would be preferable to have a single function with some
>> extra parameters so that it can do b
On Tue, Aug 22, 2017 at 2:55 AM, Ben Hutchings wrote:
> On Tue, 2017-08-22 at 01:22 +0900, Roger Shimizu wrote:
>
> Oh I see, that adds section (1 MiB) alignment in several places.
> Surprisingly, the padding isn't completely zero-filled, so it inflates
> the compressed image size too.
Good to kn
On Tue, 2017-08-22 at 01:22 +0900, Roger Shimizu wrote:
> Control: tag -1 +pending
>
> On Mon, Aug 21, 2017 at 9:28 AM, Roger Shimizu wrote:
> > On Mon, Aug 21, 2017 at 12:43 AM, Ben Hutchings
> > wrote:
> > >
> > > OK, then try using 4.11.6 source and bisecting the Debian config
> > > changes
Processing control commands:
> tag -1 +pending
Bug #870185 [linux-image-4.11.0-0.bpo.1-marvell] FATAL: kernel
4.11.0-0.bpo.1-marvell does not boot on QNAP TS-219P II
Added tag(s) pending.
--
870185: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870185
Debian Bug Tracking System
Contact ow..
Control: tag -1 +pending
On Mon, Aug 21, 2017 at 9:28 AM, Roger Shimizu wrote:
> On Mon, Aug 21, 2017 at 12:43 AM, Ben Hutchings wrote:
>>
>> OK, then try using 4.11.6 source and bisecting the Debian config
>> changes.
>
> Result:
> 0905519af414d339f615d7aac974f9a9163cdbd3 is the first bad commi
On Mon, Aug 21, 2017 at 12:43 AM, Ben Hutchings 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: [327c328b5435d93c2d3
On Sun, 2017-08-20 at 21:16 +0900, Roger Shimizu wrote:
> On Sun, Aug 20, 2017 at 6:54 AM, Ben Hutchings
> 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 p
On Sun, Aug 20, 2017 at 6:54 AM, Ben Hutchings 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 gradua
On Sun, 2017-08-20 at 02:35 +0900, Roger Shimizu wrote:
> On Sun, Aug 20, 2017 at 12:55 AM, Ian Campbell
> 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
On Sun, Aug 20, 2017 at 12:55 AM, Ian Campbell 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
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
On Mon, Jul 31, 2017 at 11:43 PM, Roger Shimizu wrote:
> On Mon, Jul 31, 2017 at 3:05 AM, Roger Shimizu 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
On Mon, Jul 31, 2017 at 11:43 PM, Roger Shimizu 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
On Mon, Jul 31, 2017 at 3:05 AM, Roger Shimizu 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.
On Mon, Jul 31, 2017 at 7:16 AM, Ian Campbell 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
On 30 July 2017 19:05:18 BST, Roger Shimizu wrote:
>On Sat, Jul 22, 2017 at 8:40 AM, Ben Hutchings
>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
On Mon, 2017-07-31 at 03:05 +0900, Roger Shimizu wrote:
> > On Sat, Jul 22, 2017 at 8:40 AM, Ben Hutchings 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
On Sat, Jul 22, 2017 at 8:40 AM, Ben Hutchings 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 l
On Sun, 2017-07-23 at 00:14 +0900, Roger Shimizu wrote:
> On Sat, Jul 22, 2017 at 8:40 AM, Ben Hutchings
> 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 unnecess
On Sat, Jul 22, 2017 at 8:40 AM, Ben Hutchings 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 curr
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
On Mon, 8 May 2017 16:03:50 +0200
Martin Michlmayr wrote:
> * Roger Shimizu [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
* Roger Shimizu [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
ht
[ CC: Martin ]
Dear Ben,
Thanks for your effort to support armel/marvell!
On Wed, 03 May 2017 23:12:40 +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 clo
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 imag
62 matches
Mail list logo
