Bug#949171: linux: Please, enable COMPACTION for armel/marvell to mitigate OOMs
emd[1]: Stopping Journal Service...
[3559321.969754] systemd-journald[134]: Received SIGTERM from PID 1 (systemd).
[3559322.475409] systemd-journal: 56 output lines suppressed due to ratelimiting
[3559322.486605] systemd[1]: systemd-journald.service: Succeeded.
[3559322.498942] systemd[1]: Stopped Journal Service.
[3559322.568880] systemd[1]: Starting Journal Service...
[3559323.616592] systemd[1]: Started Journal Service.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Can CONFIG_COMPACT please be enabled for armel (or only marvel, if that's
the case)?
Thanks in advance,
Rogério Brito.
P.S.: Please, disregard the information collected by reportbug after this,
as I am writing this message on an amd64 system. I will possibly file a bug
report regarding the TAINT_WARN for this system that I am using after I
debug it a little bit.
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing'), (200, 'unstable'), (150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.4.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.utf-8, LC_CTYPE=pt_BR.utf-8 (charmap=UTF-8),
LANGUAGE=en_US.utf-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Bug#920767: e2fsprogs: [REGRESSION] e4defrag version 1.44.5-1 segfaults on an armel system (but 1.44.4-2 doesn't)
Package: e2fsprogs
Version: 1.44.5-1
Severity: important
X-Debbugs-CC: debian-arm@lists.debian.org
Dear Ted,
I'm having a problem when running the version of e4defrag from buster on my
armel system (it's a KuroBox Pro running as a NAS box for my very small
local network).
When running e4defrag on such system, I get 100% of segfaults when I run a
command as simple as `e4defrag -v .` (both as root or as a regular user) in
whatever directory that I want.
I posted a long description of the command and running the e4defrag under
gdb at:
https://lists.debian.org/debian-arm/2019/01/msg00034.html
At the time I wrote the post above, I hadn't yet had the opportunity to
distill what I know today, which is to hunt down a working version of
e4defrag. Today, I know that reverting the packages
* e2fsprogs from 1.44.4-2 to 1.44.5-1
* libext2fs2 from 1.44.4-2 to 1.44.5-1
(and nothing else) makes the problem go away.
If you want me to provide any further detail, please let me know and I will
try my best to provide what you want (I may take a little time because
compiling programs on the armel is a bit slow, but I will do my best
anyway).
Thanks in advance,
Rogério Brito.
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing'), (150, 'unstable'), (100, 'experimental')
Architecture: armel (armv5tel)
Kernel: Linux 4.19.0-1-marvell
Locale: LANG=en_US.utf-8, LC_CTYPE=pt_BR.utf-8 (charmap=UTF-8),
LANGUAGE=en_US.utf-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages e2fsprogs depends on:
ii libblkid12.33.1-0.1
ii libc62.28-5
ii libcom-err2 1.44.5-1
ii libext2fs2 1.44.5-1
ii libss2 1.44.5-1
ii libuuid1 2.33.1-0.1
Versions of packages e2fsprogs recommends:
pn e2fsprogs-l10n
Versions of packages e2fsprogs suggests:
pn e2fsck-static
pn fuse2fs
pn gpart
pn parted
-- no debconf information
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Getting segfaults when running e4defrag
Dear people,
My armel KuroBox Pro (which is a marvell orion5x) has a filesystem that is
potentially very fragmented and I have always used the command e4defrag to
defragment it.
Unfortunately, today I tried running it as I had usually done for many years
(as "e4defrag -v ." in a directory of interest), but all that I got were
segfaults, something which I had never seen before (e4defrag has always been
very robust).
Before I file a bug report (not really sure against what package), is
anybody able to confirm the problem with an armel box?
(As an aside, I don't get these errors when I run e4defrag on my amd64
notebook, but, of course, the notebook doesn't have the HDD that I would
like to defragment.)
I installed the debug symbols package for e2fsprogs and I tried running
e4defrag under gdb and this is what I got:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
root@lattes:~# gdb /usr/sbin/e4defrag
GNU gdb (Debian 8.2-1) 8.2
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/sbin/e4defrag...Reading symbols from
/usr/lib/debug/.build-id/0b/5a1dd65aa694d5c82a5d756a1f7a0f24fcbb23.debug...done.
done.
(gdb) set args -v .
(gdb) run
Starting program: /usr/sbin/e4defrag -v .
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabi/libthread_db.so.1".
e4defrag 1.44.5 (15-Dec-2018)
ext4 defragmentation for directory(.)
[1/0] "/root"
File is not regular file[ NG ]
[2/0] "/root/.emacs.d"
File is not regular file[ NG ]
[3/0] "/root/.emacs.d/auto-save-list"
File is not regular file[ NG ]
[4/0]
Program received signal SIGSEGV, Segmentation fault.
strlen () at ../sysdeps/arm/strlen.S:33
33 ../sysdeps/arm/strlen.S: No such file or directory.
(gdb) bt
#0 strlen () at ../sysdeps/arm/strlen.S:33
#1 0xb6df6ca8 in _IO_vfprintf_internal (s=0xb6f04d90 <_IO_2_1_stdout_>,
format=format@entry=0x405978 "\033[79;0H\033[K[%u/%u]%s:\t%3d%%", ap=...,
ap@entry=...) at vfprintf.c:1638
#2 0xb6e9e5ac in ___printf_chk (flag=1, format=0x405978
"\033[79;0H\033[K[%u/%u]%s:\t%3d%%") at printf_chk.c:35
#3 0x00404350 in printf (__fmt=0x405978 "\033[79;0H\033[K[%u/%u]%s:\t%3d%%")
at /usr/include/arm-linux-gnueabi/bits/stdio2.h:107
#4 file_defrag (file=, buf=buf@entry=0xbeffa310,
flag=, ftwbuf=ftwbuf@entry=0xbeffc35c) at
../../../misc/e4defrag.c:1606
#5 0xb6e7fb20 in process_entry (data=data@entry=0xbeffc348,
dir=dir@entry=0xbeffa3c8, name=name@entry=0x420b53 ".lesshst",
namlen=, d_type=8) at ftw.c:464
#6 0xb6e7ffdc in ftw_dir (data=data@entry=0xbeffc348, st=0x0, old_dir=0x8,
old_dir@entry=0x0) at ftw.c:543
#7 0xb6e808a8 in ftw_startup (dir=, is_nftw=is_nftw@entry=1,
func=, descriptors=, flags=3) at ftw.c:768
#8 0xb6e80998 in __new_nftw64 (path=, func=,
descriptors=, flags=) at ftw.c:841
#9 0x00401a28 in main (argc=0, argv=0xbefff7a4) at
../../../misc/e4defrag.c:1914
(gdb) quit
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Of course, I have also libc6-dbg and libc6-dev installed (even though it
seems that gdb is unable to find the sources to sysdeps/arm/strlen.S, as
indicated in the line numbered with 0).
Can anybody help here, please?
Thank in advance,
Rogério Brito.
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Re: Is anyone running buster/sid on armel? if so does current udev work?
Hi, Peter and others.
On 2018-09-20 22:43, peter green wrote:
It has recently been discovered in raspbian (
https://bugs.launchpad.net/raspbian/+bug/1793415 ) that udev doesn't
start if built with gcc 8 due to what appears to be a hardening related
failure. As a result I have just forced the systemd source package
(which builds udev) in raspbian to build with gcc-7.
This issue does not appear to affect Debian armhf.
Which leaves me wondering about armel, has anyone tried udev 239-8 or
239-9 on armel? if so did it work?
I'm running testing (buster) on armel here with udev/systemd 239-9 and
everything works well with the KuroBox Pro (with 128MB of RAM).
Regards,
Rogério Brito.
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Fwd: Running Pure Debian on the Raspberry Pi 3B+?
Hi, people.
I tried to send the message below more than 12h ago, but it seems to
have been lost, so I am resending it via another relay.
Thanks in advance for any help,
Rogério.
-- Forwarded message --
From: Rogério Brito
Date: Tue, Aug 14, 2018 at 6:59 AM
Subject: Running Pure Debian on the Raspberry Pi 3B+?
To: debian-arm@lists.debian.org
Dear people,
I am thinking of getting a Raspberry Pi 3B+ and, from what I read, it is
mostly supported by the upstream Linux kernel, but I still have doubts about
what I may be losing or not, compared to Raspbian.
>From what I read, there are some binary blobs needed for the video to work
(and I would like to use it with Kodi, to play some videos and to, perhaps,
act as a NAS or a place where I can use to save some files via NFS when a
USB HD is attached to it).
Regarding hardware support, are there many customizations in Raspbian that
are not in Debian?
Regarding video, are the players available in Debian (mpv, vlc, ffplay etc.)
able to take advantage of the hardware acceleration, if all the needed blobs
are in place? I would be tracking the testing distribution (as I do with
all my other computers).
Also, when people talk about the performance of the raspberry pi and videos,
they always talk about the hardware decoding being used (which, I suppose,
is about H.264 video) and that gives no idea of how powerful the hardware is
(or is not).
To get an idea, what about the software encoding with NEON or whatever SIMD
that the is used with arm64? How are the numbers that one can get with, say,
the following command (with or without raspbian)?
mplayer -nosound -vo null -benchmark -endpos 200
big_buck_bunny_480p_stereo.ogg
(The video available from:
http://download.blender.org/peach/bigbuckbunny_movies/)
Thanks in advance for any help with understanding both running a pure Debian
distribution on the Raspberry Pi and understanding its performance (so that
I can compare with other hardware before I go on and buy one of these small
board computers).
Thanks once again,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Re: [PATCH] [armel] Add KuroBox Pro to long description of marvell kernels.
Hi, Ben and others..
On Wed, Apr 18, 2018 at 8:42 AM, Ben Hutchings wrote:
> On Wed, 2018-04-18 at 05:23 -0300, Rogério Brito wrote:
(...)
>> hardware-long: Marvell Kirkwood based systems (SheevaPlug, QNAP
>> TS-119/TS-219, etc)
>> - and Orion 5181, 5182 and 5281 based systems (QNAP TS-109/TS-209, etc)
>> + and Orion 5181, 5182 and 5281 based systems (QNAP TS-109/TS-209, KuroBox
>> Pro etc)
>
> There's also the Buffalo Terastation and Linkstatation, Linksys
> WRT350N, HP Media Vault mv2120, LaCie 2Big Network, etc.
Oh, sure. Making a long list and keeping it up-to-date is hard, but,
sometimes, doing an "apt-cache search" and finding a hit is good.
OTOH, since the kernel is already installed, people will probably not notice it.
> I think it might make more sense to refer to a wiki page here, than to
> try listing the many supported models. I just updated
> https://wiki.debian.org/ArmEabiPort with a model list for kirkwood.
Great, thanks.
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Re: armel/marvell kernel size
e
notebook where I compiled things:
1 - I would change from the CFQ to the DEADLINE governors *in the
general kernel*, as it makes the kernel slightly smaller, but, in my
experience, working as well as a CFQ in practice.
2 - Another excellent option is CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
suggested by Leigh Brown (taken from
https://lists.debian.org/debian-arm/2018/03/msg00035.html). The amount
of reduction in size with my system was surprising (much smaller than
what I expected by changing the governors or when changing some
options from y to m).
Since I mentioned my environment, please, keep in mind that:
* The compiler that I am using for everything here is the one from
testing (buster) and it is GCC 7 at the moment (have not tried using
GCC 8 to see the differences yet)
* I am optimizing things for size (which, in some cases, may be
beneficial for machines with small L1/L2 caches too)
I would change the default from optimizing for size (-Os) to
optimizing for speed (-O2) only after all the low-hanging fruit with
kernel options were decided and, then, I would think hard if it makes
sense to have -O2 with a small kernel or with the full blown kernel.
Another option suggested by Leigh in that message was that
+# CONFIG_CRC32_SLICEBY8 is not set
+CONFIG_CRC32_SLICEBY4=y
can make the kernel smaller and, if I remember the descriptions of the
options, it made sense that those would reduce the size of the kernel
both compressed and uncompressed... This would be something that I
would suggest for a general kernel also...
I am not sure about disabling the VT option as Leight suggested... I
don't think that I have ever used one of those...
I think that we can compile out YAMA from the general kernel, since, I
would believe that it is less frequently used (we can upload a kernel
with this disabled to experimental or to a personal space and ask
people to experiment it) and it is disabled by default in Debian's
kernel...
For a -mini kernel, some of the first things that come to my mind
would be to disable:
* some hardware framebuffers like the S3 and similar ones, even if
build as modules.
* your suggestion of disabling wifi drivers and the wifi subsystem
* disabling some less commonly used local or distributed filesystems
(some of which are large or demand many other options to be enabled)
or that have better functionality in userspace (like the NTFS read
support in the kernel being disabled and recommend ntfs3g to the
users), but keeping popular ones and services like ext2/3/4, XFS, NFS,
Mounting CIFS is probably a good idea, but having OCFS or other
systems, I don't know.
* disabling some partition types for the smaller kernels, after
benchmarking them...
* disabling joystick/video/audio capture etc drivers.
* disabling yama/apparmor/audit.
* disabling unused kernel algorithms or those that aren't pulled in by
any modules (I remember at least one that said: don't enable this one
unless you have an out-of-tree module that needs it).
Oh, I would *not* disable zswap from the smaller kernel, since I would
plan on going not only with zbud but also with z3fold and test the
stability and performance of the kernel with it, as machines that are
memory-starved can benefit from a higher density of compression...
When introducing a new flavor, I guess that we could make the current
flavor, instead of none, being -standard, a new one called -mini
(similar in spirit to yours) and, potentially, another called -micro
to users of DNS323 (if the -mini flavor does not fit in the 1.5MB
after all these changes)...
Furthermore, with the LTO work on the kernel, I am hopeful that
if/when it gets merged, we can make everything even smaller and be
much happier... :-) OK, I'm excited to have very small kernels despite
the kernel in general growing from version to version with more and
more features being integrated...
Please, let me know your opinions.
I will now go to bed, but I will send my patches as soon as I wake up
and deal with morning stuff. In the end, I intend to enable support
for as many things are available in the mainline (even the DNS323, for
which I don't have the hardware, but since we are with our hands
dirty, let us extend the value of those machines for the users of such
hardware...)
Thanks,
Rogério Brito.
P.S.: Only now I saw that one of your patches already implement the
option that Leigh suggested... But I think that we can use more
modular options both in the "main" kernel and in the smaller flavors.
P.P.S.: Sorry if this message is badly composed, if there are
unfinished sentences or if something doesn't make sense, but I just
wanted to make sure that the thoughts that I have here in my head get
discussed with others and not only confined to myself.
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Re: armel/marvell kernel size
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 people actually
>> need from such a kernel...
>
> Please do! I have an OpenRD box and a SheevaPlug that I’ll be happy to test
> on.
You're welcome. I don't know much about the OpenRD nor about the
SheevaPlug, but are they able to run the -marvell kernels? What was the
last version of the kernel that worked for you?
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? The
loaded modules that you have with lsmod would be nice to know.
> Thanks for keeping these old boxes alive!
There's no guarantee, but I may try. Very low probability, but not zero
probability...
Regards,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Re: armel/marvell kernel size
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... >>> >>> [...] >>> >>> As I see it, the point of installing Debian on little NAS boxes is to >>> break out of the restrictions of an embedded system. We try to >>> provide, so far as possible, the same features across all >>> architectures. >> >> It sure makes sense to provide a lot more than some kernels, but I am >> curious about some features that end up as modules like some >> framebuffer like the following: >> >> (...) >> >> Is there any reason why, say, a driver for an S3 card is enabled while >> not for a Matrox? > > I don't know; that doesn't make a lot of sense. Running make menuconfig, I can disable it without any visible loss (not yet run it, but I don't have such hardware on my Kurobox Pro). If the kernel were only for me, then I would simply kill it, and be done with it, but, as I wrote to Stefan, the logical consequence would be to enable everything that could plausibly be used... OTOH, if people haven't noticed by this time that we need some drivers, perhaps we shouldn't be enabling such a thing... (Yes, I know that enabling a given driver can, say, enable some data structure implementation from the core of the kernel and/or some crypto algorithm, which would make the kernel potentially bigger). > The Kirkwood SoCs have external PCIe links and some of the supported > devices (like OpenRD) provide PCIe expansion slots, so most PCIe device > drivers should be enabled. > >> Are there real users for those? I know that, as >> modules, they don't make the kernel bigger, but they sit there on >> disk, doing nothing (right?). > > They probably don't make a difference. Right. I suspected this much. > However there are some cases > where a modular driver may require (and select) a feature that is > always built-in. Oh, yes this I knew. >> Similarly for wifi cards like those Intel ones like iwlwifi (which is >> the one that I have in this Core 2 Duo here)... > > Prepare to be amazed: https://www.amazon.com/dp/B00OM0L9ZO This I didn't know. :-) >> OK, now to the real meat of my message. Regarding shrinking the >> kernel image, I was able to tweak things slightly (drop from 101% down >> to 98%) by disabling APPARMOR, YAMA, AUDIT, making the kernel use the >> deadline IO scheduler instead of the CFQ and making as modules the >> ones that you suggested in the original message... Is that acceptable? > > I would really rather we avoided disabling AppArmor, since it is not > only built-in but also enabled by default on all other architectures. OK, I will reenable apparmor and see what size I get before sending patches. > Still, as armel will not be a release architecture any more, I suppose > it can diverge further from the normal configuration. I saw your other email. I would like to revert this and I don't know if (finally, after more than a decade contributing to Debian as a Debian Maintainer) it is time to step up and become a Debian Developer and commit to maintain some parts of the kernel... Yes, that means that if this excursion of mine is fruitful, I will volunteer... :-) If not, then I just get the learning experience. :-) Actually, if I succeed, I would be interested in also working to get powerpc revived, since I have an iBook G3, an iBook G4 and two ppc-based kuroboxes (but one of them has only 64MB of RAM and I still have to learn this device tree syntax)... >> If so, then I will test them on my Kurobox Pro and report what works >> and what breaks. I just wanted to get things smaller by tackling some >> lower hanging fruit... >> >> Another point: from what I saw in the Debian scripts, not all >> armel/marvell systems are limited to 2MB (in particular, the Kurobox >> Pro with which I am most concerned still has 630KB of room)... > > Roger has increased the size limit to 2729712 on the sid branch, which > is the limit on the Buffalo Linkstation devices. Check whether that > matches the Kurobox Pro too. I didn't know that. I guess that I cloned the repository after he made that change... Anyway, I will check it, but the kurobox Pro is (in my understanding) very close to a linkstation... >> In the >> very worst case (of course, this is not what we want), if the kernel >> actually gets much bigger in time for the buster release, we could >> selectively drop some systems (like what was done with the DN
Re: armel/marvell kernel size
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, thanks for that hint (which Ben also replied to)...
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...
OTOH, if nobody has asked for that before, maybe there's nobody missing
such support (or they are compiling their own kernels).
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...
Thanks for your input,
Rogério.
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Re: armel/marvell kernel size
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... Quite different from a "regular" kernel that I used to compile...
>
> Don't you have access to something faster you can work on?
Unfortunately, not at this moment. My desktop (a Phenon II X4) was
fried during a power outage. :-(
> You should be able to save time and disk space by disabling debug info,
> as that won't make any difference to the eventual kernel size. You can
> do that by adding "debug-info: false" to the [build] section in
> debian/config/armel/defines.
I did that and it seems to help a bit.
> ccache can also be useful, though it doesn't help if you change a config
> symbol that affects some widely
> used header file.
Yes, I was already using ccache and I find it invaluable.
> > 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 to
> break out of the restrictions of an embedded system. We try to
> provide, so far as possible, the same features across all
> architectures.
It sure makes sense to provide a lot more than some kernels, but I am
curious about some features that end up as modules like some
framebuffer like the following:
(...)
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
CONFIG_FB_S3=m
CONFIG_FB_S3_DDC=y
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
CONFIG_FB_3DFX=m
# CONFIG_FB_3DFX_ACCEL is not set
CONFIG_FB_3DFX_I2C=y
# CONFIG_FB_VOODOO1 is not set
(...)
Is there any reason why, say, a driver for an S3 card is enabled while
not for a Matrox? Are there real users for those? I know that, as
modules, they don't make the kernel bigger, but they sit there on
disk, doing nothing (right?).
Similarly for wifi cards like those Intel ones like iwlwifi (which is
the one that I have in this Core 2 Duo here)...
OK, now to the real meat of my message. Regarding shrinking the
kernel image, I was able to tweak things slightly (drop from 101% down
to 98%) by disabling APPARMOR, YAMA, AUDIT, making the kernel use the
deadline IO scheduler instead of the CFQ and making as modules the
ones that you suggested in the original message... Is that acceptable?
If so, then I will test them on my Kurobox Pro and report what works
and what breaks. I just wanted to get things smaller by tackling some
lower hanging fruit...
Another point: from what I saw in the Debian scripts, not all
armel/marvell systems are limited to 2MB (in particular, the Kurobox
Pro with which I am most concerned still has 630KB of room)... In the
very worst case (of course, this is not what we want), if the kernel
actually gets much bigger in time for the buster release, we could
selectively drop some systems (like what was done with the DNS323)
instead of dropping an entire arch... I even think that a new,
smaller, alternative flavor of the kernel is possible to provide to
support those systems that are limited to 2MB of kernel image... (I
can commit to support that, if my initial ideas work and people accept
them).
Of course, if we could make some real magic and make our kernels much,
much smaller to support back the DNS323, that would be amazing... :-)
I guess that I will look into those LTO patches in the future...
OK, I am sending this to see if those ideas make sense, to offer my
help and, of course, to get some feedback.
Thanks,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Re: armel/marvell kernel size
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 strange, but who knows? I'm now sending it
through gmail instead of via my usual relay. I hope that this gets
through.
> On Thu, Mar 22, 2018 at 12:12 PM, Rogério Brito wrote:
>> 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 in cfg80211 that enables direct-loading of
>>>> wireless rules, which requires public key crypto in the kernel. There
>>>> doesn't appear to be any option to disable that mode, even though we
>>>> don't need it because crda still works. Maybe you could disable
>>>> wireless networking completely?
>>>>
>>>> Some options that could possibly be changed from y to m:
>>>>
>>>> - I2C, I2C_CHARDEV, I2C_MV64XXX. initramfs-tools should include I2C
>>>> drivers to the initramfs if needed, but I'm not certain.
>>>>
>>>> - MTD, MTD_CMDLINE_PARTS, etc. But I'm pretty sure this will break
>>>> some systems unless initramfs-tools is updated to include and load the
>>>> cmdlinepart module.
>>>>
>>>> - RTC_DRV_MV (and disable RTC_HCTOSYS). There's a udev rule that
>>>> should load the system clock from the first RTC if its driver is a
>>>> module.
>>>>
>>>> - SPI_ORION. initramfs-tools should include this in the initramfs if
>>>> needed, but I'm not certain.
>>>>
>>>> Some options that could possibly be disabled:
>>>>
>>>> - AUDIT. This is quite a niche feature.
>>>>
>>>> Also try comparing the complete configs over time and looking for
>>>> symbols newly set to y.
>>>
>>> Did you had a chance to look at Ben's suggestions or ideas?
>>
>> 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 with a Kurobox HD (powerpc-based; see some notes at [0])...
>>
>> [0]:
>> http://cynic.cc/blog/posts/simple-annotations-on-compiling-a-linux-kernel-for-an-embedded-platform/
>>
>> For this task, I have some questions:
>
> I have a wiki entry to help you:
> - https://wiki.debian.org/HowToCrossBuildAnOfficialDebianKernelPackage
Thank you very much for the link. It will be highly useful for experimenting.
> However, Kurobox HD is not armel, so you need to use Kurobox Pro, if
> you still have it.
Oh, sure. I do have the Kurobox Pro and that's the one which I am
planning to keep alive as much as I can (well, not that I don't plan
on keeping the other ones not alive... It's just that I am quite short
on time and that I plan on keeping the Kurobox Pro churning as it is
the one that is already well set up and so on).
The notes that I presented on the link above are explicitly for
powerpc (BTW, it seems like my ikiwiki setup is foo-barred and ate a
large part of what I wrote in that article).
As I said before, I hope to have some time before Easter to work on
getting the kernel smaller and back being produced.
Oh, just to reiterate a part from my previous email (the one that
didn't reach the mailing lists):
> 3 - Besides the points listed above, what else can usually be disabled, if
> they don't pertain/make sense in a system like a small armel box?
If anybody could comment on that, it would be very good to know, so as
to have some slack to prevent these problems from happening in the
near future.
Thanks,
Rogério Brito.
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Fwd: Looking for a small NAS that runs Debian well
Apparently, the message that I sent below via mutt and my ISP wasn't
delivered for some reason.
I'm resending it.
Thanks,
Rogério.
-- Forwarded message ------
From: Rogério Brito
Date: Tue, Dec 12, 2017 at 1:29 AM
Subject: Looking for a small NAS that runs Debian well
To: debian-arm@lists.debian.org
Dear people,
I would like to find a substitute to my KuroBox Pro, which is an armel-based
NAS. Here is its summary:
* An Orion processor running at 400MHz
* 128MB of RAM
* a slot for one 3.5" SATA HDD
* gigabit ethernet
* 2 USB 2.0 ports
That's essentially it. It works running Linux without *any* binary blob and
it is supported by the upstream Linux kernel.
Unfortunately, Debian is starting to show that it is old. In particular,
there is constant swapping when serving my video collection via DLNA
(minidlna) and the kernel has even found some problems allocating memory for
the network device. :-( Besides DLNA, I intend to use it as an NFS and Samba
server. If I can run a printer spooler, then that will be nice, but it's not
required.
I still intend to keep running it while I don't find a replacement for it,
but I would love to find something that is robust, that can run Debian and
that has low power consumption.
I don't care so much if I have to use some binary blobs, as long as the blob
is purely firmware (e.g., if the NAS needed something from the firmware-*
packages, I'd be OK with that), it is fully supported by Debian, and I can
recompile things if something in Debian stops working.
Is there anything similar to what I described above and that is a bit more
powerful? I don't particularly care what architecture it runs.
Thanks in advance,
Rogério.
P.S.: Please CC me on replies, as I am not currently subscribed to the
mailing list.
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Flood of messages in dmesg: "mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to linearize skb with tiny unaligned fragment"
73197] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to linearize
skb with tiny unaligned fragment
[815054.973239] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to linearize
skb with tiny unaligned fragment
[815054.973280] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to linearize
skb with tiny unaligned fragment
[815054.973321] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to linearize
skb with tiny unaligned fragment
[815054.973362] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to linearize
skb with tiny unaligned fragment
[815054.973407] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to linearize
skb with tiny unaligned fragment
[815054.973448] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to linearize
skb with tiny unaligned fragment
[815054.973488] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to linearize
skb with tiny unaligned fragment
[815054.973529] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to linearize
skb with tiny unaligned fragment
[815054.973570] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to linearize
skb with tiny unaligned fragment
[815054.973610] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to linearize
skb with tiny unaligned fragment
[815054.973651] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to linearize
skb with tiny unaligned fragment
[815054.973692] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to linearize
skb with tiny unaligned fragment
[815054.973814] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to linearize
skb with tiny unaligned fragment
[815054.974446] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to linearize
skb with tiny unaligned fragment
[815054.975063] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to linearize
skb with tiny unaligned fragment
[815054.975726] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to linearize
skb with tiny unaligned fragment
[815054.975771] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to linearize
skb with tiny unaligned fragment
[815054.975812] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to linearize
skb with tiny unaligned fragment
[815054.975852] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to linearize
skb with tiny unaligned fragment
[815054.975893] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to linearize
skb with tiny unaligned fragment
[815054.975934] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to linearize
skb with tiny unaligned fragment
[815054.975975] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to linearize
skb with tiny unaligned fragment
[815054.976015] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to linearize
skb with tiny unaligned fragment
[815054.976056] mv643xx_eth_port mv643xx_eth_port.0 eth0: failed to linearize
skb with tiny unaligned fragment
(...)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Is this a problem? Is there something that I could do so that I can get this
fixed?
If there is any extra information that I should provide, please let me know
and I will try my best to collect it.
Please, CC me as I am not currently subscribed.
Thanks in advance,
Rogério Brito.
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Re: Installing Debian on a Zealz GK802/imx6 dongle?
Dear Vagrant,
First of all, thank you very much for answering to my question.
On Fri, Apr 28, 2017 at 4:52 PM, Vagrant Cascadian wrote:
> On 2017-04-28, Rogério Brito wrote:
>> Anyway, revisiting this device, I am interested in getting any more
>> modern operating system on it and, of course, Debian is my first
>> choice. Does anybody here have any experience with this kind of system
>> or something similar? If yes, how have things evolved in the last 4
>> years? Is it too painful to install Debian on it?
>
> It looks like there's at least a devicetree for it in linux:
>
> arch/arm/boot/dts/imx6q-gk802.dts: model = "Zealz GK802";
> arch/arm/boot/dts/imx6q-gk802.dts: compatible = "zealz,imx6q-gk802",
> "fsl,imx6q";
>
> Several of the drivers (hdmi, microsd, usb-otg, internal usb) are
> marked as: status = "okay";
>
> The .dtb is present in the linux 4.9.x linux-image-4.9.0-2-armmp
> package. There are several other imx6 devices supported in debian's
> armhf kernels, so the necessary drivers *might* already be enabled.
> That all sounds reasonably promising.
Thanks a lot for all these status updates. I must say that I'm
completely lost in this sea of ARM hardware, with so many variants, so
many (unofficial) kernel trees (and that's not even counting the
Android trees that I just started to learn about, with the intention
of getting a more updated version of Android also working on this
device).
I really appreciate this help of yours. PowerPC like Macs are super
easy in comparison.
> So, your task will be to figure out how to get the bootloader that comes
> with it (or port it to a modern u-boot) to load Debian's kernel,
> initramfs and the appropriate .dtb file.
I experimented with things a bit during these past few days and I got
the following results/pieces of information:
* This device boots from a microSD card, which makes things
considerably lower risk in comparison with other devices, which means
that, in the worst case, I can just wipe the microsd card and start
over.
* Ignoring the Android image that came with it (and which has 9
partitions!), the only other working image that I got was the one
provided by [1], which was supposed to be a Debian 7 netinstall image.
It worked up to a point where, retrieving the packages from the
network, there was a segfault and I didn't pursue things further.
[1]:
http://projectgus.com/2013/05/debian-installer-for-zealz-gk802-android-tv-quad-core-arm-minipc/
This image has a very peculiar layout:
* The image is a regular MBR partition table (not UEFI), created with sfdisk.
* The u-boot binary that was used was put starting at 1KB from the
beginning of the image, in *an unpartitioned* area before the
beginning of the first partition. (The android image also had many
gaps between partitions, when I inspected it with gparted).
* The first real partition starts at 1MB from the beginning of the image.
* The contents of this real partition are only 3 things: a script for
uboot, a kernel image (a 3.0.x kernel, if memory serves correctly) and
an initrd that contains the netinstall parts.
Given all this information and the sea of the images and files in [2],
I'm a bit lost here on which method I should pursue further.
[2]:
http://ftp.nl.debian.org/debian/dists/testing/main/installer-armhf/current/images/hd-media/SD-card-images/README.concatenateable_images
Should I use these hd-media images (creating one for my device---but I
don't know what I should include in the potential
"firmware.gk802.img.gz", if that is the way to go) or should I use
another method, like the one given in [3].
[3]:
http://ftp.nl.debian.org/debian/dists/testing/main/installer-armhf/current/images/u-boot/MX6_Cubox-i/
Do you have any advice?
> You'll probably want to figure out how to connect to the serial
> console...
Hopefully, this is not needed... Yet. :-)
>> I can provide some details with respect to the hardware and document
>> my experiences and the installation process somewhere for reference of
>> others (kind of what Martin did with some systems on his personal
>> page) with the ultimate goal of getting it working well with Linux.
>
> There are pages for various devices on:
>
> https://wiki.debian.org/InstallingDebianOn/
Excellent. I will wait until I have success to report the results there.
Thanks,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Installing Debian on a Zealz GK802/imx6 dongle?
Dear people,
Some years ago I bought a Zealz GK802 dongle (which, if I understand
correctly from what I read on the web [0], is an imx6-based
system---but I am not sure) which came with an 8GB microsd card
running Android 4.0.
My primary intention with it would be to serve me as a device to run
Kodi, but, as soon as it was doing *anything*, it overheated and
locked hard.
I left it there gathering dust, despite it being potentially able to,
while not serving as my primary intention, act as something else, like
downloading some torrents or building some packages, given that it is
much more powerful than my KuroBox Pro with (which is an armel device
with only 128MB of RAM---of course, the IO abilities of the two
devices are mightly different).
Anyway, revisiting this device, I am interested in getting any more
modern operating system on it and, of course, Debian is my first
choice. Does anybody here have any experience with this kind of system
or something similar? If yes, how have things evolved in the last 4
years? Is it too painful to install Debian on it? If nobody has any
experience with it, I am interested in investing some effort into
getting it working, so that I can make some use of this piece of
hardware that I have here.
I can provide some details with respect to the hardware and document
my experiences and the installation process somewhere for reference of
others (kind of what Martin did with some systems on his personal
page) with the ultimate goal of getting it working well with Linux.
Thanks for any help,
Rogério.
[0]:
http://projectgus.com/2013/05/debian-installer-for-zealz-gk802-android-tv-quad-core-arm-minipc/
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Re: Problems with KuroBox Pro and micro-evtd
Hi, Ryan.
On Tue, Mar 7, 2017 at 11:11 PM, Ryan Tandy wrote:
> Hi Rogério,
>
> Sorry to hear about this issue.
>
> Is there enough info in syslog/journal to tell whether it's a graceful
> (software-initiated) shutdown or simply the hardware forcing power off?
No, there are no messages, which makes things very hard to debug.
In fact, I looked at the code and the daemon could use more messages
more being sent to syslog. :)
> I was going to mention the temperature thresholds that were adjusted:
>
> https://anonscm.debian.org/cgit/collab-maint/micro-evtd.git/commit/?id=b6a052b00cf898689dba1dd993037facaa1bf741
>
> but if that were the issue, I would expect it to cause problems when
> micro-evtd is not running, as well (since in this case nothing will trigger
> the fan to spin up).
Indeed, the limits only went up (if I didn't miss anything) and my
system seems very stable with micro-evtd disabled. Of course, none of
the functionalities of it (like pressing the button to turn the unit
off) are present then (unless I hold the button for a hard shutdown).
> 1-2 days is a very odd time period for it to survive!
Indeed, especially when, without micro-evtd or with the old
version/"old state of the world" (with respect to both the kernel and
earlier versions of micro-evtd) I get a computer that works as long as
I don't reboot it or don't have power outages.
Oh, I noticed something strange, but I don't know if it is related
somehow with micro-evtd not working. For quite some time now (let's
say, 2 or 3 years, but I don't remember when it started), whenever I
try to see the environment with fw_printenv, I get errors in the
kernel log telling me that the NAND has unrecoverable errors:
- - - - - - - -
(...)
[ 22.466531] Adding 396284k swap on /dev/sda3. Priority:-1
extents:1 across:396284k FS
[ 23.123208] EXT4-fs (sda1): mounting ext2 file system using the
ext4 subsystem
[ 23.184435] EXT4-fs (sda1): mounted filesystem without journal.
Opts: errors=remount-ro
[ 28.634334] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 31.259076] mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 1000
Mb/s, full duplex, flow control disabled
[ 31.268998] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 56.754422] NFSD: starting 90-second grace period (net c058c578)
[132923.387111] __nand_correct_data: uncorrectable ECC error
[132923.392597] __nand_correct_data: uncorrectable ECC error
[132923.398070] __nand_correct_data: uncorrectable ECC error
[132923.403519] __nand_correct_data: uncorrectable ECC error
[132923.408972] __nand_correct_data: uncorrectable ECC error
[132923.414422] __nand_correct_data: uncorrectable ECC error
[132923.419876] __nand_correct_data: uncorrectable ECC error
[132923.425327] __nand_correct_data: uncorrectable ECC error
[132923.431272] __nand_correct_data: uncorrectable ECC error
[132923.436729] __nand_correct_data: uncorrectable ECC error
[132923.442192] __nand_correct_data: uncorrectable ECC error
[132923.447663] __nand_correct_data: uncorrectable ECC error
[132923.453113] __nand_correct_data: uncorrectable ECC error
[132923.458564] __nand_correct_data: uncorrectable ECC error
[132923.464019] __nand_correct_data: uncorrectable ECC error
[132923.469468] __nand_correct_data: uncorrectable ECC error
- - - - - - - -
Note that I only get these errors if I use fw_printenv (I was going to
disable the restrictions to reading from /dev/mem and revert the
version of micro-evtd to the previous version).
I never got these errors with just a regular use of the kurobox,
regardless if I use either the old version of micro-evtd or the new
version, which leads me to think that the situation above may be
unrelated, but I am a layman here.
Thanks,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Re: Problems with KuroBox Pro and micro-evtd
Dear Roger,
First of all, I am sorry for the late reply,but I had some problems in life
that kept preventing me from reading my emails properly.
Second, I am on my phone, so sorry for top posting and spelling mistakes.
That being said, thank you very much for your reply.
I am using testing/sid on my kurobox pro, and the problem with the Kurobox
turning itself off is with the latest kernel from testing and with
micro-evtd already patched.
Unfortunately, micro-evtd does not produce many error messages/logging, so
that makes it hard to know what the problem may be.
What I can say for sure is that without micro-evtd enabled, my kurobox
doesn't turn itself off.
If there is any way that I can provide some more details, please let me
know.
Thanks once again,
Rogério.
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
On Feb 24, 2017 09:38, "Roger Shimizu" wrote:
On Thu, Feb 23, 2017 at 11:50 AM, Rogério Brito wrote:
> Hi.
>
> Since the hardening of the kernel introduced with Debian's Linux 4.8
> and micro-evtd having been changed to adapt, I have not had any luck
> with my KuroBox Pro (KBP) running any recent (>= 4.8) kernel with
> micro-evtd for more than, say, 1 or 2 days.
Dear Rogério,
Ryan and I have updated the micro-evtd 3.4-4 to support kernel >=4.8,
and you should be able to install it from jessie-backports.
Please report if you meet any issue. Thank you!
Cheers,
--
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1
Problems with KuroBox Pro and micro-evtd
Hi.
Since the hardening of the kernel introduced with Debian's Linux 4.8
and micro-evtd having been changed to adapt, I have not had any luck
with my KuroBox Pro (KBP) running any recent (>= 4.8) kernel with
micro-evtd for more than, say, 1 or 2 days.
What I get is the following: the buzzer starts beeping and, in many
cases, the KBP turns itself off *BUT* the buzzer still keeps beeping.
If I am lucky, SSH in kill micro-evtd and restart it, then the KBP
will work fine---that is, until the next time that micro-evtd decides
that something is wrong, starts the beeps and so on.
Unfortunately, micro-evtd is *very* poor regarding sending any logs (I
read the code and there are almost nothing logged). This means that
logging in via SSH, looking at the output from dmesg or from
journalct, there is nothing there.
After this, I have disabled micro-evtd and, from that point on, I'm
with an uptime of 16 days.
Does anybody see anything similar to what I'm seeing? Perhaps it might
be the case of reverting the patch and returning to the previous
version of micro-evtd?
Thanks for any feedback,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Feedback from armel tester
Hi.
This is just a quick feedback from an armel tester.
I'm using a KuroBox Pro that Martin gave me a few years ago with Debian
testing and everything works perfectly with kernel
linux-image-4.7.0-1-marvell.
I had some 100% reproducible issues with kernels around 4.4 that I never
managed to report due to some sad personal problems, but the issues went
away and I am running said kernel for about a week so far.
Thanks,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org/blog : Projects : https://github.com/rbrito/
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Re: orion5x housekeeping
Dear Roger.
On 2016-03-02 06:57, Roger Shimizu wrote:
> On Wed, Mar 2, 2016 at 2:06 PM, Rogério Brito wrote:
>> Dear Martin and others,
>>
>> On 2015-12-31 00:51, Martin Michlmayr wrote:
>>> I was looking at debian-installer and thought it would be good to see
>>> if there are maintainers (and if not, at least users) for the orion5x
>>> devices we supposedly support.
>>
>> Right.
>>
>>> Looking at debian-installer, I see support for:
>>>
>>> * Buffalo Kurobox Pro: I know various Debian people had these. Are
>>> people still using these devices? Is Debian working? Is the
>>> installer working?
>>
>> I can confirm that the Kurobox Pro is working fine with testing, with
>> kernels 3.16.x and with kernel 4.4.
>
> Thanks for your feedback!
> Good to hear it's working for you!
Oh, and now I have one extra data point: using the xz compression for
the initrd also works very well, apart from its creation being
considerably slower. With the adoption of MODULES=dep and xz
compression, the initrd went from 10MB to 2.8MB.
Not that the Kurobox Pro had problems with the large initrd (it does
have problems with the rest of the userspace slowly growing), but it is
nice to have everything leaner.
If we only could have a leaner compiled samba (say, to only cite one
example), without all the bells and whistles that the current debian
package has, that would be a very good thing for these machines with
128MB of RAM.
>> Now, with kernel 4.4 and recent flash-kernel, everything is working fine.
>
> I guess it's because the updated flash-kernel fixed your previous
> issues with 4.x kernel.
I guess so. If I recall correctly, I had a problem when booting and the
last message was something like "machine id foo unsupported". I can't
remember right now...
> code of Kurobox-Pro didn't changed since long before.
I suppose here that you meant the kernel code, right? I would guess
that, apart from changes in modules like the ethernet module with TSO
being problematic, the rest hasn't changed in a very long while in a
substantial way.
>> I didn't test the installer, though. I may test it soon, depending on
>> availability of my time and interest from other people.
>
> Actually I'm doing some work on the installer for Linkstation
> orion5x/kirkwood recently.
> Hope you can help to test after I finish.
Sure. Just ping me and I will do my best.
> And I plan to write kernel's device tree for Kurobox/Pro.
> Unfortunately, I don't have this device. If you're convenient, you can
> help to test this, too.
I would like to understand this device tree thing a little bit more.
I have a PowerPC-based Kurobox HG that used to have all the MTD
partitions auto-detected and now I have to pass the partition layout by
hand via the command line, which is a bummer.
I know very little about both the device tree and the hardware to know
where to "graft" the subtree related to the MTD partitions on the whole
tree representing the device.
>> Just to be sure, I changed /etc/initramfs-tools/initramfs.conf to have
>> the variable MODULES set to dep instead of most, which greatly reduced
>> the size of the initial ramdisk.
>
> Yes, MODULES=dep is enough for most cases for Linkstation.
Yes, the hardware doesn't change that much. :)
> Good to know you also maintain avr-evtd, which works for old powerpc
> based Linkstation.
Yes, besides the plan regarding the device tree thing cited above, I
would also like to:
* Add support for the Kurobox HG to the debian-installer.
* Have native uboot support for the Kurobox HG, so that I can have all
the goodies since 2006 in my bootloader *and* the boot partition being
ext4, instead only ext2.
* I plan on modularizing avr-evtd, separating the parser part of it to
be more robust and making sure that the rest of the daemon actually
works well.
The code for avr-evtd is quite flaky, with way too many global variables
in its only C file and it needs a heavy dose of patience to understand
some parts of the code (and some were just plain wrong).
Despite the fact that this second Kurobox is a powerpc-based one, the
userspace works very well, but I understand that most knowledgeable
people regarding uboot, device trees and so on are here on debian-arm...
Thanks,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Re: orion5x housekeeping
Hi, People.
On 2016-03-02 02:06, Rogério Brito wrote:
>> * Buffalo Kurobox Pro: I know various Debian people had these. Are
>> people still using these devices? Is Debian working? Is the
>> installer working?
>
> I can confirm that the Kurobox Pro is working fine with testing, with
> kernels 3.16.x and with kernel 4.4.
I just went ahead and edited Roger Shimizu's table of
supported/unsupported hardware with information about the Kurobox Pro at:
https://wiki.debian.org/rosh/PortingStatusForDebianInstaller
I guess that this table could be promoted to something higher to a more
visible place (perhaps "installing debian on"?) so that it could assume
a more formal status.
Furthermore, the table there is too wide. At first, I didn't even notice
that there were fields for sid!
It, perhaps, could be broken with sections on "support since" (is this
really necessary? perhaps users would like to know which stable version
of the distribution they can "safely" install?), "support changing" and
"current support/sid"?
Anyway, I guess that this work is not worthless. And, yes, I would like
to have this hardware supported until it dies.
Thanks,
Rogério.
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Re: orion5x housekeeping
Dear Martin and others,
On 2015-12-31 00:51, Martin Michlmayr wrote:
> I was looking at debian-installer and thought it would be good to see
> if there are maintainers (and if not, at least users) for the orion5x
> devices we supposedly support.
Right.
> Looking at debian-installer, I see support for:
>
> * Buffalo Kurobox Pro: I know various Debian people had these. Are
> people still using these devices? Is Debian working? Is the
> installer working?
I can confirm that the Kurobox Pro is working fine with testing, with
kernels 3.16.x and with kernel 4.4.
It ceased to work for a brief period, but I was very busy with life in
general (a costly separation from my ex-wife, very serious health
problems with my mom etc.) and I just decided to hold the kernel at
3.16, while kernels 3.1{7,8,9} and early 4.x didn't work (had to use a
serial cable to revert to a working kernel).
Now, with kernel 4.4 and recent flash-kernel, everything is working fine.
I didn't test the installer, though. I may test it soon, depending on
availability of my time and interest from other people.
> Roger mentioned u-boot restrictions on the size of the kernel that we
> broke. Does that apply to all Linkstation devices? Do we have to
> drop support for all of them in stretch?
Given the way that the Kurobox Pro boots (namely, grabbing everything
from disk), I would expect fewer problems with it than with similar
platforms.
Just to be sure, I changed /etc/initramfs-tools/initramfs.conf to have
the variable MODULES set to dep instead of most, which greatly reduced
the size of the initial ramdisk.
10243401/boot/initrd.buffalo-3.16.7-ckt11-1+deb8u6
10171147/boot/initrd.buffalo-3.16.0-4-orion5x
10164753/boot/initrd.buffalo-3.16-3-orion5x
10084248/boot/initrd.buffalo-3.14-2-orion5x
4396975 /boot/initrd.buffalo-4.4.2-3
4396975 /boot/initrd.buffalo
4323087 /boot/initrd.buffalo-3.16.7-ckt20-1+deb8u1
4288911 /boot/initrd.buffalo.bak
4288911 /boot/initrd.buffalo-3.16.7-ckt20-1+deb8u3
My last few kernel images have size:
1990840 /boot/uImage.buffalo-4.4.2-3
1990840 /boot/uImage.buffalo
1566456 /boot/uImage.buffalo-3.16-3-orion5x
1565904 /boot/uImage.buffalo-3.14-2-orion5x
1560904 /boot/uImage.buffalo.bak
1560904 /boot/uImage.buffalo-3.16.7-ckt20-1+deb8u3
1560880 /boot/uImage.buffalo-3.16.0-4-orion5x
1560528 /boot/uImage.buffalo-3.16.7-ckt20-1+deb8u1
1559632 /boot/uImage.buffalo-3.16.7-ckt11-1+deb8u6
Hope that, while late, this report might still find use.
Thanks,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
Specifying the MTD partitions in a device tree
Hi.
I am sending this message to Debian/powerpc, Debian/arm lists because and
linuxppc-dev. While the issue that I'm having is with a powerpc machine,
the arm people may also be of valuable help with device trees, since they
have to deal with them seemingly all the time.
Anyway, the problem that I have is as follows: I have a Kurobox HG (powerpc)
NAS that Riku Voipio donated me a few years ago.
Everything worked fine and I was able to get Debian (since kernel 2.6.20 or
similar) running up to with kernels 2.6.28 (if my memory serves me well).
With kernel 2.6.29, the partitions of the MTD device that this machine has
were not displayed anymore (only one big device was presented to the user).
In a recent exchange [0] with Scott Wood from the linuxppc-dev, I was
finally able to partition the MTD flash device with the original layout of
the device by passing an `mtdparts` option to the kernel.
[0]: http://permalink.gmane.org/gmane.linux.ports.ppc.embedded/80215
It seems, though, that the proper way to fix this issue for good is to
include such description in the DTS files for the particular board (in fact,
at least 2---but potentially 4---boards are affected by this).
I tried a few experiments with writing a patch to the existing dts files,
but I wasn't successful, since I am not sure about a good amount of the
things and I would appreciate some assistance here.
In particular, I don't know if I filled all the fields correctly and, also,
I don't know where I should "graft" the description of the flash chip in the
rest of the device tree.
Can anybody help here? I am sending a verbosely and dirty patch (not yet
suitable for inclusion in the main kernel tree) that I created (and which
didn't work) with as much information that I know about the system, but I
can surely collect more information.
Ideally, I would like to get many of the things automated and add support
for the Kurobox HD/HG to the Debian installer, so that people with these
devices can breathe new life into their systems (instead of the original
2.4.20 kernel that came with it).
I would ge greateful for anybody that can help here. I hope to both learn
and help with the maintainance of such machines.
Once again, thanks a lot for any help,
Rogério Brito.
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
>From a4e80dc8edb19d323318900020e5cb2e010bda94 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rog=C3=A9rio=20Brito?=
Date: Thu, 14 May 2015 02:42:22 -0300
Subject: [PATCH] arch/powerpc: dts: First try at specifying partitions for the
Kurobox HG.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This is based on my (successful) experience with partitioning the MTD flash
device of the Kurobox HG by passing the `mtdparts` option to the kernel.
For the sake of documentation, the option that works is:
mtdparts=physmap-flash.0:3072k@0k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf),4096k@0k(full)
Unfortunately, my attempts at mimic'ing the line above in
arch/powerpc/boot/dts/kuroboxHG.dts didn't bear fruits so far.
Signed-off-by: Rogério Brito
---
arch/powerpc/boot/dts/kuroboxHG.dts | 68 +
1 file changed, 68 insertions(+)
diff --git a/arch/powerpc/boot/dts/kuroboxHG.dts b/arch/powerpc/boot/dts/kuroboxHG.dts
index 0e758b3..e3de7fb 100644
--- a/arch/powerpc/boot/dts/kuroboxHG.dts
+++ b/arch/powerpc/boot/dts/kuroboxHG.dts
@@ -143,5 +143,73 @@ add flash parts, rtc, ??
0x7000 0x0 0x0 0x4 &mpic 0x3 0x1
>;
};
+
+ /* Based on a mix of information from:
+ - personal experiments
+ - http://buffalo.nas-central.org/wiki/Flash_ROM
+ - Documentation/devicetree/bindings/mtd/mtd-physmap.txt
+ - Documentation/devicetree/bindings/mtd/partition.txt
+ */
+ flash@fff8 {
+ compatible = "amd,am29lv320" /* Fujitsu 29PL32TM-90PFTN 4MB Flash ROM chip */, "cfi-flash";
+ reg = <0xfff8 0x40>;
+ bank-width = <1>; /* "Found 1 x16 devices at 0x0 in 8-bit bank." */
+ device-width = <1>; /* unneeded? */
+
+ /* linux,mtd-name = <>; */ /* FIXME: unneeded? */
+ /* use-advanced-sector-protection = <>; */ /* FIXME: unneeded? */
+ vendor-id = <0x0004>; /* "Manufacturer ID 0x04" */
+ device-id = <0x007e>; /* "Chip ID 0x7e" */
+
+ erase-size = <0x1>; /* 64 KiB */
+
+ #address-cells = <1>; /* FIXME: verify */
+ #size-cells = <1>; /* FIXME: verify */
+
+ /*
+
+ My (rbrito) u-boot currently uses:
+
+ mtdparts=physmap-flash.0:3072k@0k(firmimg),448k@3072k(bootcode),64k@3520k(status),512k@3584k(conf),4096k@0k(full)
+
+ For reference:
+
+ * 3072KiB = 0x300
"Expanding" memory of an armel device?
Hi.
My kurobox pro (an armel orion5x machine) has a very limited amount of
memory ("only" 128MB). Unfortunately, it seems that the programs in Debian
are only getting bigger not only on disk, but also requiring more memory
(and this includes the Linux kernel).
It constantly needs to use swap and running a simple `apt-get update &&
apt-get upgrade` (with pdiffs disabled) is super painful, taking many
minutes to run.
Since we don't have zram or similar modules in our kernel to try to
alleviate the situation, I was thinking of, perhaps, using some kind of fast
solid state memory to be used as swap.
Unfortunately, (I have not tested this yet) it seems that using a USB thumb
drive wouldn't help much: the speed that I get from the SATA HD reading
sequentially from the swap partition with `ddrescue` is about 40MB/s and I
expect a USB thumb drive to be considerably slower (of course, there would
be some extra factors to factor in, like the latency of accesses---I suspect
that the disk seeks in the HD to be non-negligible during the swap
activities).
That being said, the kurobox pro has a PCI Express connector. Is there any
cheap peripheral that I could buy that would help me with the task of
"expanding" the memory of this NAS?
Thanks,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150226124712.ga13...@ime.usp.br
Alternative java/JVM working on armel/powerpc?
Hi there.
I would like to run some programs that require a JVM on "alternative"
platforms, like armel/powerpc (these are arches for which I have hardware
running Debian, but others might also be of interest). (Please, feel free
to cross-post this message to other ports, if you deem this to be relevant.)
But anything related to Java is too slow on such architectures with the
default, unoptimized Zero JVM and I'm having some problems while trying to
use other JVM implementations that we have in the archive.
Based on this information, is there anybody out there that can help with
investigation of what works and what doesn't? I would love it if people
could perform a simple test by installing the packages scala and clojure1.4?
* Running clojure and typing "(+ 1 1)" (without the quotes) should give you
back the answer 2.
* Running scala and typing "1 + 1" (again, without quotes) should also give
you back the answer 2.
For each of these cases, does it get faster if you type it again (in which
case the JVM might be caching things)?
After that, can you install alternative JVMs? The packages are:
* jvm-7-avian-jre (for the Avian JVM)
* icedtea-7-jre-jamvm (for JamVM).
To make each be use by default, simply reorder the lines in
/etc/java-7-openjdk/jvm-.cfg
In particular, does running with avian even work? All I got was an illegal
instruction. It is supposed to be a fast and memory efficient JVM and would
be a great thing to get running on arches where you can't upgrade your
memory as easily as with amd64 or i386.
Thanks in advance for any help here,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org/blog : Projects : https://github.com/rbrito/
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140710021334.ga5...@ime.usp.br
Mini-HTPC that runs Debian?
Dear all,
Now that with XBMC announcing support for Android devices, there seems to be
a great proliferation of small computers running Android >= 4 that are sold
to be used as HTPCs.
For example, I found the following to be interesting:
https://dx.com/p/177875
https://dx.com/p/176074
I am mostly asking this because my wife is threatening to kill me if,
according to hear, I don't give her something that is able to play games on
the TV (I don't quite get what is so special about the "on the TV", but I
think that it is better not to ask).
I couldn't care less for the games, but I do care for video playback,
especially those that I encode with handbrake (which was my motivation to
get it into Debian, as you can see in the git repo of the Debian multimedia
team).
OK, so, the questions:
1 - Is it possible (without too much pain) to run a Debian on these things?
2 - If it is possible, would one of these be useful as a mini buildd?
3 - Is it possible to run X on this? Would it be accelerated for video
playback? What if I happened to grab the Android kernel (don't know how
one would do this, since I have never used Android)?
4 - If I were not to tinker with these computers and content with only using
Android for the games, which one should one prefer?
I think that the first device linked above has a "Vivante GC2000" GPU, while
the second has a Mali GPU.
If these computers listed above are not good, are there any recommendations
for a computer that would fit the 4th point (read: "the wife point") above,
but also allow me to install one Android program or another that I happened
to write?
Thanks a lot for any feedback that you may provide,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org/blog : Projects : https://github.com/rbrito/
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130324085629.ga6...@ime.usp.br
Re: Can't get a Linux 3.6-rc zImage smaller than 2MB
Hi, Maciej,
On Mar 23 2013, Maciej Soltysiak wrote:
> > Just curious: Can you install the package advancecomp and run on that
> > ramdisk the command:
> >
> > advdef -z -4 ramdisk.gz
> >
> I've different files, but here goes. Less by 127 kB:
> 3385295 3254732 96% initrd.img-3.8.3-iop32x
Well, even if the difference is small, that may be the difference between
being able to squeeze it in the memory or exceeding the alloted size.
And 127kB is not neglibible, as there are many modules that would fit in
that space (more if we consider that they will be compressed).
> root@Koryto:/tmp# advdef -z -4 vmlinuz-3.8.3-iop32x
> File type not supported on vmlinuz-3.8.3-iop32x [at void
> convert_inplace(const std::string&):redef.cc:490]
>
> Maybe I could try to do it on the uncompressed image? I'm actually
> recompiling at the moment, so will try later.
A compressed Linux image is, in my understanding, more than simply gzipping
the image itself, which means that a plain advdef won't work, but I'd love
to be proven wrong.
Thanks,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org/blog : Projects : https://github.com/rbrito/
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130323194214.ga22...@ime.usp.br
Re: Can't get a Linux 3.6-rc zImage smaller than 2MB
Hi.
On Mar 20 2013, Chris Wilkinson wrote:
> File sizes are:
>
> Initrd.img/ramdisk.gz – 2425607
Just curious: Can you install the package advancecomp and run on that
ramdisk the command:
advdef -z -4 ramdisk.gz
and report back the results? Just to be extra safe, you may want to test the
recompressed image with:
gzip -t ramdisk.gz
If the image gets smaller, then you probably will have some space to put one
binary or another in it, so that said image will be more useful.
> Vmlinuz/zImage – 1524976
I don't know how, but it would be nice to see how much improvement one would
get from doing the same trick as above.
Regards,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org/blog : Projects : https://github.com/rbrito/
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130323154730.gc8...@ime.usp.br
Re: SSD in a Qnap TS-110 ?
Hi there.
On May 22 2012, Ruediger Leibrandt wrote:
> When search time is the issue, a SSD is an enormous speedup. The only
> thing even faster are Ramdrives - those boxes you plug in DIMM-RAM's - but
> there you'll end up with a 16GB drive for 90€, and I doubt you're needing
> the 600MB/s throughput on read & write that these drives offer.
Where can I get more information about such ramdrives? A quick search with
Google has only returned things like "how to create ramdrives from my
computer's RAM".
I would be interested in one of these for use as swap for ARM machines that
are (always?) memory starved. If one could just throw some cheap SDRAM into
one of these ARM boxes...
Are there any potentially hacky solutions, like the [FatSlug][0] for other
computers? This, perhaps, with ZRAM, could be used to alleviate the issue of
running with little RAM.
It seems that RAM is a more or less general problem about ARM, as per the
discussion of the buildd's for armel and armhf qualifications.
Regarding disks, for NASes that have two bays, it seems that using an SSD
with a regular HD, then the [benefits of bcache are promising][1].
[0]: http://www.nslu2-linux.org/wiki/HowTo/FatSlug
[1]: https://lwn.net/Articles/394672/
Regards,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org/blog : Projects : https://github.com/rbrito/
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120523151906.ga14...@ime.usp.br
Re: armel v4t vs v5
Hi.
On Apr 18 2012, Wookey wrote:
> +++ Martin Guy [2012-04-18 14:30 +0200]:
> > How big is the speed advantage for
> > v5 users when optimizing for v5 instead of v4t? Enough to warrant the
> > exclusion of our v4t parts?
>
> I just asked and the answer seems to be 'some, but not much'. There
> are a few more useful instructions which should amount to a few
> percent speed improvement, but the gains are not exciting, which does
> suggest leaving it at v4t until really no-one cares anymore.
This is an interesting discussion, as trying to understand the
variety/diversity of ARM is like a big puzzle to people used to more
"regular" platforms like amd64 and i386.
In the same fashion as the question above, what would the benefits of
compiling some selected packages (like what Mike Thompson is doing for the
R-Pi) to an armel such as:
,[ cat /proc/cpuinfo ]
| Processor : Feroceon rev 0 (v5l)
| BogoMIPS : 265.42
| Features : swp half thumb fastmult edsp
| CPU implementer : 0x41
| CPU architecture: 5TEJ
| CPU variant : 0x0
| CPU part : 0x926
| CPU revision : 0
|
| Hardware : Buffalo/Revogear Kurobox Pro
| Revision :
| Serial:
`
Reading Wikipedia, it seems that the E in the "5TEJ" as reported by Linux
could be of some use (akin to MMX/SSE?)
BTW, talking about ARM, the very fact that ARMvx != ARMx is confusing to
newcomers and, if I understand it correctly, for Linux, what is important is
the thing with "v" (e.g., ARMv5TEJ).
BTW#2, is there any application in Debian (or is GCC actually able to
generate code to) use Jazelle?
Thanks for any guidance for this misguided soul,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org/blog : Projects : https://github.com/rbrito/
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120503212057.ga1...@ime.usp.br
Re: ARM kernel cross compilation issues for iMX53
Hi there.
On Mar 19 2012, Paul Shirren wrote:
(...)
> The Beagle XM only has 512M
Nice that this was brought up, so I can ask: are all ARM machine generally
memory-starved, in comparison with other platforms?
I know very little of the platform, but I have always kept an eye here, and
it seems that there is nothing similar to what one has on the x86 world,
where one can simply grab some upgrade of the memory card and pop it it.
Is that impression correct? In case it is, is there any "common" [*]
solution that uses, say, a mini-PCIe card to be like, say, something
intermediary between real memory and a swap partition on a disk.
[*] For sufficiently small values of common. :)
Say, a swap partition on a flash/whatever device?
Regards,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org/blog : Projects : https://github.com/rbrito/
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120329195347.ga20...@ime.usp.br
Re: Support for the D-Link DNS-320?
Hi, Jari.
On Mon, Feb 20, 2012 at 11:32, Jari Kirma wrote:
> I have also been running Debian on TS-419P+ as my general-purpose server
> for a while. QNAP provides nice NAS software that Debian doesn't really
> challenge on its' turf, but for general-purpose services, combination of
> Debian and QNAP hardware are a great, hassle-free combination.
I suspected that, since Martin's document are excellent guides telling
what works and they seem to be fully supported.
> There's one minus side I must recognize: QNAP boxes can't compete with D-Link
> on price
> alone.
Indeed. I just checked the TS-410 and it costs 1592.40USD(!). The
TS-419P+ isn't on their local site and I would venture to guess that
it would be almost 1800 or so, which make them unfeasible for me.
Thanks for sharing your experience also,
Rogério Brito.
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAOtrxKNf=uDO9+prVadaFQnvDqvsYdFPEQTWv+i+kme=rpf...@mail.gmail.com
Re: Support for the D-Link DNS-320?
Dear Björn,
On Mon, Feb 20, 2012 at 10:56, Björn Wetterbom wrote:
> I don't know about the DNS-320, but I would heartily recommend the QNAP
> products, preferrably the ones with official Debian support via
> www.cyrius.com.
>
> I'm running two older Qnaps as servers 24/7 with excellent track record.
I would love to have one QNAP box, but they are mightly expensive here
in Brazil: on their site here,
http://www.qnapbrasil.com.br/detalhes.asp?cod=467872
the price of 2406.69BRL is equivalent to 1401.68USD, according to google. :(
Thanks for sharing the experience, BTW.
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAOtrxKN3Ok9K4X1svf5dqs`ruNciMZVBy�xuhsqtbwc...@mail.gmail.com
Support for the D-Link DNS-320?
Hi, people.
I just saw a guy selling a D-Link DNS-320 and, according to D-Link
themselves, these devices run Linux. Looking on the Linux kernel tree
I see that there is a file called dns323-setup.c (for the 323), but
there is no mention of the 320.
Of course, if I happen to buy one of these, I would wipe everything
and install a real debian system.
So, my question is: are there successful reports of people using the
DNS-320? Some googling seems to indicate so, but I don't know which
kernel would be appropriate, if everything works correctly etc.
Also, is this a good purchase? I would love to get a NAS device that
can hold 2 HDs, but I have no brand loyalty and I mostly only care
about installing Debian on it. If you happen to know other devices
that would be a better choice, I would love to know.
Thanks in advance for any recommendation,
Rogério Brito.
P.S.: As I am not currently subscribed to debian-arm, I would kindly
ask if you could include me in CC.
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/caotrxkogy064pqqfauy+cmvfz0+dbdhacg_q8qucu7eufdu...@mail.gmail.com
Re: Experiences on using zram with ARM?
Hi.
2011/7/14 Rogério Brito :
> As many ARM systems (and other embedded architectures) happen to be
> memory-starved, I thought about playing with zram (the new name of
> "zramswap") on some of my systems, but I found out that not all platforms
> have zram enabled in the stock kernels in Debian.
>
> So, my question is: does anybody have experiences running zram with
> non-{i386,amd64} platforms? It would be nice to know before I start
> compiling many kernels and stuff.
I sent this message about 5 days ago and I didn't have any responses
in debian-arm. For that reason, I am resending it to debian-arm and
also crossposting it to debian-{powerpc,user}. Any experiences shared
here regarding the use of "compressed ram" would be more than welcome.
Just for the record, if the module is available, it should be simply a
matter of issuing:
modprobe zram # load the module
echo 67108864 > /sys/block/zram0/disksize # size of RAM to reserve to
be compressed
mkswap /dev/zram0 # create a swap in that area
swapon /dev/zram0 # use the swap on the compressed RAM
The basic idea here is that by compressing a portion of RAM:
* we may be able to hold more content in RAM.
* while we use some CPU cycles, it should beat the option of going to disk.
So, again, if anybody has any feedback on using this on a non-x86
arch, it would be very much appreciated.
Thanks,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAOtrxKMVO4J=t_nt5pe1q0foswrugkgs3vulponipoeka6g...@mail.gmail.com
Experiences on using zram with ARM?
Dear people,
As many ARM systems (and other embedded architectures) happen to be
memory-starved, I thought about playing with zram (the new name of
"zramswap") on some of my systems, but I found out that not all platforms
have zram enabled in the stock kernels in Debian.
So, my question is: does anybody have experiences running zram with
non-{i386,amd64} platforms? It would be nice to know before I start
compiling many kernels and stuff.
Thanks in advance for your comments,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110715004535.ga12...@ime.usp.br
Installing Linux on an oddball computer?
Hi there.
My uncle just loaned me a strange netbook from an apparently Taiwanese
company. The netbook is called "Powerpack NET-807" and it looks like
this:
http://www.powerpack.com.tw/front/bin/ptdetail.phtml?Part=8-0001&Category=309741
It runs Windows CE 5.0 and this thing is *so* limiting (my Nokia N900
is way more flexible than this) and I would love to run Linux on it.
Unfortunately, I don't even know the architecture that this thing
runs, but on the "My Computer" icon of Windows CE, it says that it has
a "Samsung, ARM-ARM920" [sic] processor.
OTOH, it came with an SD card that has the installation for Windows CE
and I was looking at some of the executables there and, by inspection
with file, this is what I got:
"Skype.exe: PE32 executable for MS Windows 32-bit"
Actually, *many* of the executables in that SD card give me the same
output. Does this mean that they are x86 binaries?
The method for installation of things in this computer is also unusual
to me: the SD card has a big file with a ".nb0" extension and it seems
to be loaded when you hold the power button for, say, 5 seconds or
more.
Is there anybody here that even has a passing experience with such a beast?
Besides that, the Taiwanese company seems to be in danger of some GPL
violation, as it contains some ffmpeg code, but I have yet to see the
sources anywhere in their site...
Any help here would be more than welcome.
Thanks,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/BANLkTi=yyxpe8y8ogphktrlcczvjbe0...@mail.gmail.com
Re: Kurobox Pro recovery
Dear John,
On Thu, Aug 26, 2010 at 15:09, John DiMarco wrote:
> I haven't had any luck whatsoever (partially for lack of time to work on
> it), and nobody (until you) replied to my message, so I'm really glad you
> sent me your note.
Did you find any time to test my previous suggestion of booting with
the foonas-em kernel/initrd, set the environment variables and install
a full-powered Debian system? I would like to know.
> I've also got a linkstation live that I need to upgrade, so I'm hoping the
> kurobox approach will work for that. Though I can always revert that to
> the buffalo firmware using tftp if necessary, not an option for the kurobox.
What exactly is the issue that you have with the linkstation? And
which linkstation is that one?
>>http://rb.doesntexist.org/blog/2010/05/11/simple-annotations-on-compiling-a-linux-kernel-for-an-embedded-platform/
>
> That seems really helpful, I'll definitely keep a pointer to it, thanks.
You're welcome. Please, just keep in mind that that particular page is
mostly talking about a PowerPC-based kurobox, but some of the
information is also relevant to other embedded arches using uBoot.
> It's nice to know someone on the debian list is still using the Kurobox;
Yes, I have three Kuroboxes: 2 that are PPC-based and the more
powerful one that Martin sent me. I am starting to fix things and I
hope to be able to develop things further. In particular, I want to
see why micro-evtd is not speeding up the fan (or I may not be hearing
very well).
Regards,
--
Rogério Brito : rbr...@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/aanlktikiybphzbecdo+on6rptylon0xorjisvukmv...@mail.gmail.com
Re: Kurobox Pro recovery
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dear John,
On 08/09/2010 11:19 AM, John DiMarco wrote:
(...)
> Symptoms: the kurobox grabs
> both files by tftp, then after a short pause, reboots; repeat ad nauseum.
(...)
I don't know if you solved that already or not. I was thinking of talking with
Martin during this year's Debconf, since I had *exactly* the same behaviour (and
my Kuro Pro was donated by Martin himself).
I have solved it (after quite some silly work), by grabing foonas-em uimage
(renamed and put onto the tftp directory with a silly initrd, since the uboot
bootloader would request one). [1]
Once I did that, I could log into the kurobox, set the nvram variables by myself
and have everything working, so that I could, after that, install Debian's
unstable (the one that I use).
> Unfortunately I don't have a serial interface on my kurobox
> pro so I can't quite see what specifically is going wrong.
Right. That's my situation too. Using a network console is much easier than
using a serial console (but, of course, more limited too).
I don't know if the vanilla uboot has a network console enabled (not played with
it yet), but that makes everything easier.
Having a network console on the kernel is also not a bad idea. You can see the
appropriate options for this on a page of mine. [2]
[1] http://www.foonas.org/index.php/Foonas-em:kuropro
[2]
http://rb.doesntexist.org/blog/2010/05/11/simple-annotations-on-compiling-a-linux-kernel-for-an-embedded-platform/
Hope this helps,
- --
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkx2p7MACgkQCFqbMnwsrrhfRQCfV4XElBQoMvOj9PjTcqeSMMRL
nJoAn2QPuqw2zWwqYYf7/jzxdtgbsn59
=fILA
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c76a7b4.8090...@ime.usp.br
Looking for help with maintainance of a package
Dear people,
I am the maintainer of hfsprogs, which is a package taken from Apple's
Darwin code that provides a mkfs.hfs{,plus} and, more importantly,
fsck.hfs{,plus}.
Unfortunately, the present version has problems not being 64-bit clean
and, as a result, I had to restrict the list of architectures to those
that are 32 bit only.
This has been reported as bug #436159 on our bug tracking system. As I
myself have all the interest to have this package available on as many
architectures as possible (since, in particular, I use an amd64 machine,
but keep some of my data/backups on external HDs formatted with HFS+),
it would be ideal to have it as arch: any.
But alas, it is not. :-( It won't compile without a number of patches
and I have already got Gentoo's patch as a starting point for the
package. But it would be better to have it divided as a series of
independent patches (as I already use quilt to manage the patches). I
have already started doing this.
Seeing that Apple has released a new version to match their Leopard
release, it would be a good thing to keep the patches separate as some
parts will apply nicely while others are obsolete now (the code has
changed a bit, but not much).
As I posted on ubuntuforums.org [*], for this goal, I would like to see
if there are interested developers so that I would create a project on
Alioth to maintain patches that are team-maintained and which would
clean up miscoding, warnings, consistency, correctness and, perhaps,
submit them upstream so that we can reduce our work in the future (and
have a more solid filesystem for exchange of data between computers).
I have already made a package yesterday that uses the 32-bit emulation
of amd64 to have a functioning fsck.hfsplus program and I plan on
uploading it to experimental, but it is based on older source code, not
on the new upstream version (let's move one step at a time).
So, that is it. If you have interest and know of more people interested
in this (like Ubuntu people), please let me know. BTW, as I am not
subscribed to any specific Debian list nowadays (besides
-devel-announce), I would appreciate CC's.
Regards, Rogério Brito.
[*] http://ubuntuforums.org/showthread.php?p=4919975
--
Rogério Brito : [EMAIL PROTECTED],ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
signature.asc
Description: Digital signature
Re: Bug#376159: Open21xx Bug Report
Sorry for the comment, but I may be missing something obvious here:
On Aug 13 2007, Matej Vela wrote:
> Michel Dänzer <[EMAIL PROTECTED]> writes:
> > Given the list of failing architectures, I think the most likely
> > cause is some code relying on char being signed by default. And
> > indeed, building the as21 directory with -fsigned-char makes it
> > build for me.
>
> You're right, as21/cpp.c was comparing a plain char to EOF. I've
> uploaded the attached patch, let's see if it works.
Theoretically (and practically also), an EOF should *never* be compared
to a char: only to an int.
> --- open21xx-0.7.5.orig/as21/cpp.c
> +++ open21xx-0.7.5/as21/cpp.c
> @@ -235,7 +235,7 @@
> /* - 2 to leave room for testing comments and quotes */
> while (chars_read < max_size - 2)
> {
> -ch = buf[chars_read] = getc( yyin );
> +buf[chars_read] = ch = getc( yyin );
> if (ch == EOF)
> {
> goto read_done;
I would first read the character from getc, then see if it is EOF and,
depending on the comparison, do whatever is needed. Otherwise, I would
judge the code to be incorrect and losing precision in a case where such
precision should not be lost.
Regards, Rogério Brito.
--
Rogério Brito : [EMAIL PROTECTED],ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
