On Fri, Nov 21, 2008 at 03:25:57PM +, Ian Campbell wrote:
I've added this to the svn tree. Please can you try a snapshot kernel
(see http://wiki.debian.org/DebianKernel) with at least r12404
In the status page I see that 2.6.18.dfsg.1-24~snapshot.12410 is still
waiting for amd64_etch build.
On Sat, Nov 29, 2008 at 11:17:59AM +, Ian Campbell wrote:
Apparently there is no Etch amd64 autobuilder at the moment. I've done a
private binary-only build and put the bits here:
Thanks, I'll try it out on one of the domUs and let you know how it goes.
It will take some time as the errors
Same thing happening here every few days. I managed to get some more info
using crash utility and a core generated with xm dump-core. To get a
vmlinux with debug symbols I recompiled the linux-image-2.6.26-2-xen
package with CONFIG_DEBUG_INFO.
The strange thing is that it seems to be stuck on
Got some more info by dumping the hung machine registers with
'xm debug-keys d' and 'xm dmesg':
(XEN) *** Dumping CPU3 host state: ***
(XEN) [ Xen-3.2-1 x86_64 debug=n Not tainted ]
(XEN) CPU:3
(XEN) RIP:e008:[828c8010cd51] __dump_execstate+0x1/0x60
(XEN) RFLAGS:
Further investigation showed that process address space randomization
in 2.6.26-2-xen-amd64 and 2.6.26-2-amd64 is causing random segfaults
in exim4 and python. Problem can be reproduced by starting exim4 in
a loop:
# ulimit -c unlimited
# for ((i = 0; i = 10; i++)); do exim4 -bV || break;
Not sure if this is relevant but recompiling the kernel with LOCKDEP
enabled produces this during domU boot:
[0.004000] [ cut here ]
[0.004000] WARNING: at kernel/lockdep.c:2658 check_flags+0x53/0x14c()
[0.004000] Modules linked in:
[0.004000] Pid: 0,
Hi,
Any chance this could be fixed for jessie release?
--
Valentin
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141029005435.ga9...@gavran.carpriv.carnet.hr
The machine from the original report has been working stable for
a while now, so I confirm this is probably fixed in wheezy kernels:
linux-image-3.2.0-4-amd64 version 3.2.78-1 running at the moment.
--
Valentin
Package: src:linux
Version: 4.9.25-1
Severity: wishlist
Dear Maintainer,
Please consider enabling this module used for tracking the state
of TCP connections. Similar probes for other protocols are already
enabled:
CONFIG_NET_DCCPPROBE=m
CONFIG_NET_SCTPPROBE=m
-- System Information:
Debian
Package: src:linux
Version: 4.9.25-1
Severity: wishlist
Dear Maintainer,
Please reconsider enabling CONFIG_SLUB. Other distro kernels
(CentOS7, Ubuntu 16.04) and upstream kernel are already using
SLUB as the default allocator.
-- System Information:
Debian Release: 9.0
APT prefers unstable
Hi,
The problem seems to be caused by the new multi-queue xen blk driver
and I was advised by the Xen devs to increase the gnttab_max_frames=256
parameter for the hypervisor. This has solved the blocking issue
for me and it has been running without problems for a few months now.
I/O to LUNs
On Sat, Jan 06, 2018 at 03:08:26PM +0100, Yves-Alexis Perez wrote:
> According to that link, the fix seems to be configuration rather than code.
> Does this mean this bug against the kernel should be closed?
Yes, the problem seems to be in the Xen hypervisor and not the Linux
kernel itself. The
Package: linux-image-4.9.0-7-amd64
Version: 4.9.110-1
Severity: important
After upgrading the kernel from linux-image-4.9.0-6-amd64 to
linux-image-4.9.0-7-amd64 several domU servers crash on boot
with this message:
[1.209087] general protection fault: [#1] SMP
[1.209095] Modules
On Fri, Oct 19, 2018 at 12:41:32PM +0200, Guido Günther wrote:
> Can you reproduce this bug when you disable libvirtd to start at boot
> and then start libvirtd later on? Is this maybe tied to a specific VM
> being auto started (that gets the GPU passed in or similar)?
Yes, I disabled libvirtd
ested the patch for rootskel (also attached here for
review):
https://salsa.debian.org/installer-team/rootskel/-/merge_requests/2/diffs
--
Valentin
>From bbe911902ce1f3001efb8dac3302d17a332e3f87 Mon Sep 17 00:00:00 2001
From: Valentin Vidic
Date: Sun, 17 May 2020 14:39:18 +0200
Subject: [PATCH] T
Source: linux
Version: 5.10.28-1
Severity: normal
Dear Maintainer,
Debian installer for bullseye fails to find any disks for installation
due to a missing module for virtio block device. Merge request for
including virtio_blk (and other standard scsi modules) is here:
On Mon, May 03, 2021 at 08:58:02AM +0200, John Paul Adrian Glaubitz wrote:
> > The same issue exists on s390x but isn't apparently going to get fixed
> > so we need to have d-i be smarter (hence the merge request)?
>
> Seems so.
QEMU console might get fixed in the kernel, but it looks like LPAR
17 matches
Mail list logo
