Package: linux-image-4.9.0-4-amd64
Version: 4.9.65-3
Severity: important
Affects: openafs-modules-dkms
debian/patches/debian/keys-limit-abi-change-in-4.9.59.patch renames
register_key_type to register_key_type_2 without bumping the ABI counter,
breaking OpenAFS kernel modules (package openafs-modu
control: tags -1 - moreinfo + fixed-upstream
control: found -1 3.16.39-1+deb8u1
There is a report at https://wiki.debian.org/HP/ProLiant to the effect that
this was no longer an issue in kernel 4.6.3 from jessie-backports.
Upstream commit
https://git.kernel.org/cgit/linux/kernel/git/stable/linu
control: fixed -1 4.9.2-2~bpo8+1
I confirm that the latest kernel in jessie-backports does not suffer from
this problem.
Am building a patched 3.16.39 (it compiles OK) but won't be able to test it
until the next maintenance window for the affected system.
I have some more information about [what I believe to be] this problem.
We've had similar incidents from several clients, running kernels 3.16.{36,39}
and 4.9 (jessie-backports). I think this rules out a client hardware issue.
The trigger (from the client's perspective) seems to be loss of contac
Package: linux-image-3.16.0-4-amd64
Version: 3.16.36-1+deb8u1
One of our systems is suddenly unable to stat() a particular file
(cookies.sqlite-wal in a user's Firefox profile). Any attempt to
do so hangs in the system call, as shown by strace. The file resides
on an NFSv4 share (sec=krb5p). Other
This has now been seen several times on two different clients (so it
probably isn't a hardware issue such as bad RAM; the second client has
ECC). The backtraces vary slightly but always involve NFS. I haven't found
a way to recover without a reboot.
I'm now upgrading these systems to the kernel fr
* micah anderson [2019-01-20 21:03:53 +0100]:
> I'm not disputing this bug exists, I'm just trying to determine why it
> is you set the severity to "Serious". As you are probably aware, this
> severity indicates that this is a sever violation of Debian policy
> (violates a "must" or "required" dire
* Ben Hutchings [2017-12-11 15:59:38 +]:
> I don't think there's any good way to deal with this
> now, other than to force a rebuild of the module.
Was afraid of that. It's what I did, of course, but it complicates the rollout.
(I ran "dkms remove openafs/1.6.20 -k $(uname -r); dkms install
o
rpc.svcgssd is also needed on clients in order to support NFSv4.0 callbacks.
It was moved from nfs-kernel-server to nfs-common for this reason. See
Debian bug #651558.
Apparently the task of starting rpc.svcgssd under SysV init is still entrusted
to the nfs-kernel-server package. Maybe something n
Package: nfs-common
Version: 1:1.3.4-2.1
Severity: serious
Tags: fixed-upstream patch
One of my systems has logged
rpc.gssd[1168]: WARNING: handle_gssd_upcall: failed to find uid in upcall
string 'mech=krb5'
This turns out to be a known problem, covered extensively in
https://bugzilla.redhat.com
Source: nfs-utils
Version: 1:1.3.4-2.1
Tags: patch
https://tracker.debian.org/pkg/nfs-utils mentions "Problems while searching
for a new upstream version". The reason turns out to be that the version
string pattern in debian/watch matches .. as well as 2.3.1 etc. and uscan
treats .. as newest. A m
Control: retitle -1 nfs4_reclaim_open_state: Lock reclaim failed
For what it's worth, I've seen the same symptoms in jessie (kernel 3.16.36
at the time) and Ubuntu trusty (3.13.0-93). In my experience, NFSv4 in
stretch is no worse than in jessie.
Rate-limiting those "Lock reclaim failed!" message
control: severity -1 normal
control: tags -1 + moreinfo
Dear reporter,
I'm sorry to hear that you have lost data. However, it doesn't seem very
constructive to make a bug release-critical without providing enough detail
to make a fix possible. NFS is a complex network protocol, and the root cause
found 416393 2.6.18.dfsg.1-18etch5
thanks
Saw the following, at exactly the same time (to the second), on three nodes
of a 21-node cluster running a LAM/MPI application. In case it matters,
the nodes are all dual-Xeon E5430 running in 64-bit mode.
Jun 2 11:50:36 rama19 kernel: BUG: warning at
Source: linux
Version: 4.9.88-1
Severity: wishlist
Tags: patch
I've run into this capacity limitation in stretch, which is addressed
upstream in Linux 4.15 by the following commit:
commit 44d8660d3bb0a1c8363ebcb906af2343ea8e15f6
Author: J. Bruce Fields
Date: Tue Sep 19 20:51:31 2017 -0400
to have solved the problem for
me.
As far as I can tell the bug is still present upstream, and has been for many
years (that "goto out" is from 2007 and replaced a "return" so the bug is even
older than that).
Marking "important" since this has actually caused
It was added to linux-firmware.git after 2022-10-12, should be in 20221109:
commit 06dbfbc74388a2e9a7228f4215b884a3139ece56
Author: Gregory Greenman
Date: Wed Oct 26 12:15:12 2022 +0300
iwlwifi: add new FWs from core69-81 release
Add the -69.ucode firmwares for the currently suppo
* Salvatore Bonaccorso [2021-05-09 22:37:02 +0200]:
> Control: tags -1 + moreinfo
>
> Do you still can reproduce the issue with a recent kernel?
No, I haven't seen it in a while (and never with 4.9 or 4.19 either; nor with
5.10 but that's statistically less significant).
When doing this (or sooner?), please also take over (and absorb)
orphaned package libnfsidmap, the upstream for which was merged
into nfs-utils three years ago.
tags 728255 + security fixed-upstream
thanks
My question was answered in an upstream git commit, sadly post-1.2.8 so it
isn't in any Debian or Ubuntu packages yet. Please cherrypick this commit:
author Signed-off-by: NeilBrown
Tue, 28 May 2013 16:59:22 + (12:59 -0400)
commit
See my report of the same bug(*) in Ubuntu at
https://bugs.launchpad.net/debian/+source/linux/+bug/1348670
(*) identification based on a comparison of the stack traces and on the
fact that it is a regression introduced in 3.2.60.
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.d
Package: nfs-common
Version: 1:1.3.4-2.5
Severity: minor
After upgrading to buster, systemd issues the following warning:
systemd[1]: /lib/systemd/system/rpc-statd.service:13: PIDFile= references path
below legacy directory /var/run/, updating /var/run/rpc.statd.pid →
/run/rpc.statd.pid; please
Package: linux-image-4.9.0-8-686-pae
Version: 4.9.144-3
Severity: normal
We have a VIA CN700-8237R board (with a Centaur C7 CPU). The kernel says
DMI: /CN700-8237R, BIOS 6.00 PG 11/25/2009
This used to boot successfully with 4.9.130-2, but consistently fails with
4.9.144-3. It also boots success
major(dev) is defined as a macro in which is provided by
libc6-dev. I don't see that listed as an explicit build dependency, so it's
conceivable that it might be present in some build environments but not in
others. The configure script tests for it, potentially leading to #define
MAJOR_IN_SY
Please don't.
I'm running an NFSv4.1 environment with sec=krb5p and autofs-ldap just fine
without this.
The rpc.idmapd(8) man page says among other things:
"Note that on more recent kernels only the NFSv4 server uses rpc.idmapd.
The NFSv4 client instead uses nfsidmap(8), and only falls back to
I have empirical reasons to believe that the fix for CVE-2019-3689 (cf. #940848)
will take care of this bug as well.
Package: nfs-common
Version: 1:1.2.6-4
This appears to be a regression caused by the fix for CVE-2013-1923.
Symptoms (hostnames and IP addresses have been changed but nothing else):
Oct 29 14:29:39 MYHOST rpc.gssd[15905]: ERROR: Cannot determine realm for
numeric host address while getting real
Package: linux-image-3.16.0-4-amd64
Version: 3.16.7-ckt20-1+deb8u3
Seen on an ASUS B150M-C motherboard with BIOS version 0806 (the latest as of
this writing), booting in UEFI mode. The problem is hardware-dependent, I'm
not seeing it on my other jessie hosts with the same kernel. (None of the
othe
A closer look at the events around t=9s (when the page cache mode is switched
to WB) pointed to mcelog as a suspect. Indeed the problem went away after
purging the mcelog package. With mcelog (104-1) installed I was getting the
following message in the logs:
mcelog: failed to prefill DIMM database
* Sergio Gelato [2016-03-04 09:12:14 +0100]:
> I still think there is a kernel issue here: mcelog shouldn't be able to
> request the wrong page cache mode and spoil things for everyone else.
It turns out that mcelog, just like dmidecode, mmap()s portions of /dev/mem,
which results i
* Ben Hutchings [2016-03-04 20:16:18 +]:
> On Fri, 2016-03-04 at 11:12 +0100, Sergio Gelato wrote:
> > A workaround may be to teach mcelog (and dmidecode, while we're at it)
> > to use the /sys/firmware/dmi interface when available.
>
> As another motivating point,
I think I've made some progress towards figuring out what's going on here.
First I looked at the Xen mini-os kernel, which keeps time correctly.
I added a few printk()s to getttimeofday() and saw that of the values
in the HYPERVISOR_shared_info structure, the vcpu_info data change often
(never mor
severity 534978 normal
thanks
I've made some more progress in understanding this behaviour, and have now
figured out a workaround. I find the documentation at
http://wiki.debian.org/Xen very misleading in several respects.
The domU kernel is receiving time info from the hypervisor as it should.
Package: linux-image-2.6.26-2-686
Version: 2.6.26-21lenny4
I periodically walk through local filesystems compiling file ownership
statistics. On one large XFS filesystem on one server, the process has
started failing after about 42 days uptime. This is the second time I
see these symptoms; the fir
Package: linux-image-2.6.26-2-686-bigmem
Version: 2.6.26-15lenny3
Severity: important
I'm running this kernel in a Xen domU using the xen clocksource:
# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
xen
The dom0 is running linux-image-2.6.26-2-xen-686 (same version 2.6.26-
tags 512617 + patch
thanks
I'm unfortunately able to reproduce this bug on an HP dc7900 with the
latest available BIOS (V1.11).
The patch in 2.6.28 looks trivial to backport to 2.6.26: it consists simply of
replacing WARN_ON with WARN_ON_ONCE. See
http://git.kernel.org/?p=linux/kernel/git/stable/
Package: linux-image-2.6.32-5-amd64
Version: 2.6.32-28
Severity: normal
On this hardware:
00:14.2 Audio device [0403]: ATI Technologies Inc SBx00 Azalia (Intel HDA)
[1002:4383]
Subsystem: ASUSTeK Computer Inc. M4A785TD Motherboard [1043:836c]
Kernel driver in use: HDA Intel
01:05
* Ben Hutchings [2010-12-12 03:10:35 +]:
> This might be a problem with the headphone detection feature. You could
> try to disable this by turning off the 'Jack Detect' switch.
I would, if I knew how. amixer mentions no such switch.
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists
* Ben Hutchings [2010-12-13 02:15:03 +]:
> On Sun, 2010-12-12 at 11:41 +0100, Sergio Gelato wrote:
> > * Ben Hutchings [2010-12-12 03:10:35 +]:
> > > This might be a problem with the headphone detection feature. You could
> > > try to disable this by turning o
Package: nfs-common
Version: 1:1.2.2-4
On a VM where autofs is being kept rather busy mounting and unmounting NFS
shares I get a stream of messages like the following:
rpc.gssd[513]: ERROR: can't open /var/lib/nfs/rpc_pipefs/nfs/clnt1ac6: No such
file or directory
rpc.gssd[513]: ERROR: can't ope
Package: linux-2.6
Version: 2.6.32-48
If I upgrade the linux-image package on a running system from
2.6.32-46 to 2.6.32-48, then run
modprobe binfmt_misc
before rebooting, the kernel fails to load the module and reports
binfmt_misc: Unknown symbol bprm_change_interp
That symbol wa
Package: linux-image-3.2.0-2-686-pae
Version: 3.2.18-1
On a fresh wheezy install I got a flood (~ 50 kHz) of messages of the following
type:
Jun 5 09:54:17 hostname kernel: [ 14.410948] [drm] nouveau :01:00.0:
PFIFO_CACHE_ERROR - Ch 0/7 Mthd 0x1470 Data 0x4956cc77
Jun 5 09:54:17 hostname
* Jonathan Nieder [2012-06-06 11:30:00 -0500]:
> Please test 3.4.1 from experimental (it should finish building and
> show up at incoming.debian.org soon[1]).
>
> Hope that helps,
Sorry to disappoint you. That 3.4.1-1~experimental.1 build
(3.4-trunk-686-pae #1 SMP Wed Jun 6 15:11:31 UTC 2012 i686
* Andrea Arcangeli [2012-06-07 12:33:55 +0200]:
> I guess if Xen can't be updated to handle an atomic64_read on a pmd in
> the guest,
I'm not sure if it makes a difference, but just in case: I observed the
problem in a dom0.
>we can add a pmd_read paravirt op? Or if we don't want to
* Jonathan Nieder [2012-02-25 21:19:43 -0600]:
> Sergio Gelato wrote:
>
> > The problem turned out to be due to an inappropriate BIOS configuration
> > setting. The "Front Panel Select" setting needed (for my specific case)
> > to be set to "AC97"
* Ben Hutchings [2012-02-27 14:50:45 +]:
> On Mon, 2012-02-27 at 09:06 +0100, Sergio Gelato wrote:
> > * Jonathan Nieder [2012-02-25 21:19:43 -0600]:
> > > Sergio Gelato wrote:
> > >
> > > > The problem turned out to be due to an inappropriate BIOS co
46 matches
Mail list logo
