| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
This dissolves the user.aszlig.system.kernel module, which was not only
to stay on the latest bleeding edge kernel but also to enable BFQ. The
latter has been factored out already a while ago already.
Originally, I had a fully custom kernel config for mmrnmhrm and dnyarri,
but it's no longer the case and thus the user.aszlig.system.kernel
module is now no longer needed.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
| |
Not everybody likes to have the latest release canidate kernel, so we
now have an option called vuizvui.system.kernel.bfq.enable, which *only*
enables the BFQ scheduler per default.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @devhell
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I previously wrote that patch in a hurry, so I thought it would be
enough to set CONFIG_DEFAULT_IOSCHED to "bfq". But in block/elevator.c
the actual default for blk-mq is a constant and can't be configured via
CONFIG_DEFAULT_IOSCHED.
So we're now patching just that constant and nothing more.
Also, I've enabled CONFIG_DM_MQ_DEFAULT, because the DM devices need to
be switched to blk-mq as well and for example on dnyarri I'm actually
using the device mapper for LUKS.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
| |
The mainline kernel only allows switching schedulers via sysfs and for
each individual device. I don't want to do that so let's do this with a
small patch so we can set BFQ as the default blk-MQ scheduler.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
| |
We're using kernel 4.12 and the BFQ scheduler is included there as a
blk-BQ scheduler, so instead of the patch, let's just use a config where
we set BFQ to be used as the default scheduler.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
| |
A lot of crap has been accumulated there over the years, so I'm removing
at least the stuff that I have introduced.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously in d6848012b86088cbfd70666a0cfae95c567e7199 I've just rebased
the patch I had against 4.10 against kernel 4.11, but that didn't work
out so well.
So this is now a rebase against the new branch from Paolo Valente at:
https://github.com/linusw/linux-bfq/tree/bfq-v8
Hopefully this time it will compile ;-)
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's basically only a very small change, because block/Makefile now
contains objects for block-MQ schedulers (one of these will also include
BFQ in possibly the next mainline kernel) and thus the patch no longer
applies.
Having that potch here in the source tree is a lot of crap lying around,
so we better get rid of it ASAP.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
First of all, using .patch from the GitHub compare view is not going to
work because the concatenated diffs are in reverse order for use within
"git apply".
And the second thing why it's not working is that the patch has a hunk
that changes the version in Makefile to add an extra version -rc1-bfq,
which would only apply for kernel 4.10-rc1 but not for subsequent
release canidates.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch is from https://github.com/linusw/linux-bfq/tree/bfq-v8.
It's a combined patch until the parent of the branch's head, because the
latest commit is a work-in-progress commit.
I have only tested evaluation and didn't test whether the patch actually
applies yet, because the machines currently using the BFQ patch are
broken because the old BFQ patch no longer applies for kernel 4.10.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've been patching these machines up since ages and I'm tired now to do
both kernel configs *again* for the recent kernel versions.
Of course, in the long run I still want them to have their customized
kernel, but right now it's better to have a recent generic kernel rather
than have a fucked up custom kernel.
Also, this removes all that cruft for the Intel HDA pinning on dnyarri,
because the machine now has two X-Fi sound cards.
Both machines probably won't boot now, so we'll have to adjust a few
things very soon.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
| |
This now should reflect "all things kernel" and thus could not only
contain patches but other things. If we have so many patches that it
makes sense to namespace them further, we can still use kernel/patches
for that purpose which is way better than "kpatches".
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
| |
Since NixOS/nixpkgs@da36847d925058fd86f027b64cc712c57be11ad8 we no
longer need so much cruft to specify kernel patches, so let's switch to
boot.kernelPatches instead of the hackery we had so far.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
| |
Gah, yes, I'm still waking up and my eyes are not working already...
Accidentally copy & pasted tho wrong hash in there.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
| |
Nothing very scary here, just getting things up to date.
This also reflects on my choices of kernel options, most of them
probably are unnecessary but I'm going to rip apart the whole kernel
config very soon[TM] anyway.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
| |
This is -rc3 + 17 commits ahead.
Configuration is once again just to get it to compile, the only new
configuration option that I really want to consider using is
CONFIG_FS_ENCRYPTION, everything else is just "updating config to latest
kernel".
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
| |
By coincidence I now got *exactly* the -rc5 tag :-)
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Geesh, the configuration is getting more and more rotten and it's time
to make this in a more generic configuration *very* soon.
The configuration does have a lot of cruft in it because it's a bunch of
"make oldconfig" iterations and no cleanup in-between.
In addition, even if I'd do the cleanup I'd probably want common options
to be factored out.
But for now let's keep the config as-is until 4.6 comes out and we
either play the "make oldconfig" game again or we finally rewrite it.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
| |
This is -rc8 plus 36 commits ahead.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
| |
This is -rc4 plus 16 commits ahead.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Version 4.3-rc5 is from the stone age and we really want to have the
latest and greatest :-)
The kernel is actually not -rc3 directly but 5 commits ahead (current
upstream master).
I've cleaned up the config for mmrnmhrm a bit, though it is still quite
messy and I might do it fully from scratch very soon[TM].
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
| |
Using -rc4 really feels rather old, so let's get it to latest upstream
master, which is exactly -rc5 without any additional commits at the
moment.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's actually v4.3-rc4 plus 34 commits ahead.
Also I'm being a bit lazy if it comes to the configuration here, adding
modules I probably won't need. That's because I currently don't have the
time to read more into the details.
Anyway, in the future I'd like to unify kernel configuration anyway, so
the laziness hopefully won't stay around for very long. :-)
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
| |
It has been a long time (~2 months) since I've been back to my
workstations, so there was a new kernel release in-between.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
| |
Oh noes... we're too old, no particular reason for updating the kernel
rather than the consistent urge to stay on mainline master.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
| |
It's about time I update these machines to the latest and greatest
kernel. Not much to say about the config as it's mostly catching up with
new options, although I'm still not happy to do configuration manually
without generalizing common options.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
| |
Fast-forward for 23 commits, which include fixes for sound, pci,
pm-sleep and nios2.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
| |
Plus 30 commits more (akpm, drm-fixes, media-fixes).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
| |
They're just a few commits from 7fc377e..6c310bc and 24 changed files,
with 156 insertions and 93 deletions, so this really isn't necessary,
but I want to have that -rc6 instead of -rc5.
Actually, this isn't really -rc6 anyway, but -rc6 plus 9 more commits.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
| |
Installing the GRUB bootloader to non-existing devices of mmrnmhrm to
for example dnyarri is not going to help anyone, right? ;-)
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
| |
Stress over the last few days affected my machines being not up-to-date
anymore. This has to change!
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Just moving the overrides into the base profile isn't enough here,
as we wouldn't be able to refer to packages anymore, because the global
nixpkgs.config override is now gone.
Instead, we're now putting pkgs.vuizvui.* into the NixOS module system
by a new profiles/common.nix, which is used unconditionally for all
machines.
Of course, the result of this is that we now need to change all
references to vuizvui-related packages, which also is a good thing,
because we will no longer shadow existing packages from upstream
nixpkgs.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
| |
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
This means, we don't have that lib directory anymore and also we're not
doing text substitution on the kernel config but instead override the
original attributes.
However, this needs to be refactored even further, so we can use the
NixOS kernel system, which allows for certain modules to require
specific kernel features. That way we can automatically create a kernel
config from the list of required features and we only need to set a
specific base config instead of specifying the *full* kernel config.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|