> For buster, we generate a cloud kernel for amd64. For sid/bullseye,
> we'll also support a cloud kernel for arm64. At the moment, the cloud
> kernel is the only used in the images we generate for Microsoft Azure
> and Amazon EC2. It's used in the GCE images we generate as well, but
> I'm not sure
> Kernel 5.6 was released yesterday
> from upstream, so isn't it a bit late
> now for 5.5?
>From what I've seen, it's not unusual for Debian's kernel team to wait
several minor point releases until there is a kernel they're happy with -
indeed, I wouldn't be surprised if the policy is to wait unti
I had a look at and it appears to have gone into both 5.3 (final) and
5.2.15.
For what it's worth, it took only a day or so to exhibit the issue on our
(admittedly active) nginx/postgres/PHP server; we weren't doing any unusual
work during that time. If you're using btrfs, and you can't apply a pa
We seem to have run into this yesterday on a production server sing a
custom compile of the 5.2.9 buster-backports kernel. nginx was hung in D
status, sync hung as well, no obvious reason for it; I ended up having to
reset the machine.
On boot I found we had lost several hours of logs and worse, s
> Can you please share with me the names of original team
> who developed debian os and its kernel.
There are several hundred Debian Developers and Maintainers:
https://www.debian.org/devel/
Since Debian was founded in the 1990s many have joined and left the project,
but a few key names are here
> Does the linux kernel work with amd ryzen processor
> series in Debian 9.0 "stretch" ?
It seems to test out fine:
http://www.phoronix.com/scan.php?page=article&item=amd-ryzen-6linux
A fix for Zen CPU multiprocessing topology was added in 4.10:
https://git.kernel.org/pub/scm/linux/kernel/git/tor
Package: linux-image-amd64
Version: 4.9+80
Debian's use of the SLAB allocator combined with ongoing kernel changes mean
the ext4 inode cache wastes ~21% of space allocated to it on recent amd64
kernels, a regression from the ~2% waste in jessie.
SLAB enforces a first-order allocation (i.e. 4KB
memory cgroups decreased the stability of 4.8, regardless of whether they
were actively being used; we were not actively using them, but still
experienced lockups. Disabling them on the kernel command line fixed it.
I'm not sure if it's been fixed in 4.9 because I removed memcgroups them
from o
> I have the impression that there is an increased probability
> for linux-image-4.8.0-0.bpo.2-amd64-unsigned (4.8.11-1~bpo8+1)
> to run into "CPU#x got stuck for 22s" messages.
This appears to be due to the cgroups memory controller. I've had had good
experience with adding cgroup_disable=memory
This appears to be due to the cgroups memory controller. I've had had good
experience with adding cgroup_disable=memory on the kernel boot line.
You can also compile your own kernel without the the memory controller,
which I recommend if you have the capability, as it cuts out a non-trivial
amo
Whoever handles this (Zumbi?) might want to hold off on making
linux-image-686-pae in jessie-backports
==
linux-image-4.7.0-0.bpo.1-686-pae-unsigned (or similar)
I run nginx caches on Debian Jessie which I keep up to date
with backports kernels. I saw the 4.7 above, so I tried it, but
I've starte
11 matches
Mail list logo
