On Sat, 19 Oct 2024 16:13:04 +0200 Bastian Blank wrote:
> This is a Debian 11? What about upgrading to the latest stable?
Yes this is Debian 11
> What are the qemu command line options?
Will dig around, but we have since disable QLX in favor of virtio
(though it is inferior) for stability's s
Package: src:linux
Version: 6.11.2-1
Severity: important
Dear Maintainer:
kworker/0:0+events spin causes high (>1) cpu load due to qxl_fence_wait.
Symptom is >1.0 load though cpu utilization is nearly zero and ps shows no user
space process consuming CPU time or stuck in iowait.
# uptime
12:05
Package: src:linux
Version: 5.6.7-1
Severity: grave
Tags: upstream
Justification: renders package unusable
This OOPS renders system unusable:
May 17 06:28:33 kernel: [541237.462244] BUG: kernel NULL pointer
dereference, address: 0068
May 17 06:28:33 kernel: [541237.462252] #PF: sup
Linux stupid 4.19.0-4-amd64 #1 SMP Debian 4.19.28-2 (2019-03-15) x86_64
GNU/Linux
[707082.059290] WARNING: CPU: 2 PID: 377 at
drivers/net/wireless/intel/iwlwifi/mvm/tx.c:1431 iwl_mvm_rx_tx_cmd+0x1e6/0x650
[iwlmvm]
[707082.059292] Modules linked in: tcp_diag inet_diag nfnetlink_queue
nfnetlink_
No longer seeing it in 4.19.0-3
Not fixed in
Linux stupid 4.19.0-1-amd64 #1 SMP Debian 4.19.12-1 (2018-12-22) x86_64
GNU/Linux
[297269.085315] WARNING: CPU: 1 PID: 451 at
drivers/net/wireless/intel/iwlwifi/mvm/tx.c:1431
iwl_mvm_rx_tx_cmd+0x1e6/0x650 [iwlmvm]
[297269.085321] Modules linked in: ufs
https://github.com/torvalds/linux/commit/20932750d9c78d307e4f2f18f9c6a32b82b1e0e8
is not in
https://elixir.bootlin.com/linux/v4.18.8/source/net/mac80211/rx.c#L1614
Not fixed in 4.18.8-1
WARNING: CPU: 3 PID: 379 at
/build/linux-GZkygY/linux-4.18.8/drivers/net/wireless/intel/iwlwifi/mvm/tx.c:1410
iwl_mvm_rx_tx_cmd+0x3d1/0x630 [iwlmvm]
Yes, this patch fixes the issue but I don't think it will actually appear in a
release until 4.19 or even later. For now I have to hand patch home built
kernels.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
199967 – iwlwifi: 3160: warning at intel/iwlwifi/mvm/tx.c:1369 triggers
frequently
https://github.com/torvalds/linux/commit/20932750d9c78d307e4f2f18f9c6a32b82b1e0e8
Package: src:linux
Version: 4.14.12-2
Severity: important
Tags: upstream
Problematic code here (line 1359):
https://elixir.free-electrons.com/linux/v4.14.12/source/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
case TX_STATUS_FAIL_DEST_PS:
/* the FW should ha
Package: src:linux
Version: 4.14.7-1
Severity: normal
Tags: upstream
Problematic code here (line 1359):
https://elixir.free-electrons.com/linux/v4.14.7/source/drivers/net/wireless/intel/iwlwifi/mvm/tx.c
case TX_STATUS_FAIL_DEST_PS:
/* the FW should have sto
At net/sunrpc/svc.c line 355 svc_pool_for_cpu(), srv->sv_nrpools can be
zero:
return &serv->sv_pools[pidx % serv->sv_nrpools];
Similar to the problem reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=1427493#c31
Jun 5 11:41:06 ospylac kernel: [ 1155.573913] divide error: [#1] SMP
Jun 5 11:41:06 ospylac kernel: [ 1155.573929] Modules linked in: joydev
rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache binfmt
This is getting ridiculous
$ ps -ef | grep "NFSv4 callback" | wc
12311087998
$ uptime
10:44:26 up 5 days, 18:28, 1 user, load average: 0.11, 0.06, 0.07
On Sat, Apr 15, 2017 at 05:09:18AM +0100, Ben Hutchings wrote:
> This bug report has severity 'normal', which does not justify an NMU.
> Also, as we are approaching the release of Debian 9 'stretch', even
> updates by a maintainer should only fix important bugs.
I don't think "normal" makes sense
Is anyone maintaining this package?
Is it possible to put this patch into an NMU?
On Thu, 2 Feb 2017 21:55:28 -0800 Nye Liu wrote:
> This bug is still not fixed.
>
> In addition, it doesn't appear as though "-V 2" will enable NFSv2,
which seems to
> be disabled by default now.
Even worse, the old nfs-common script would automatically enable
On Fri, 3 Feb 2017 01:55:10 -0800 Nye Liu wrote:
> Why is /lib/systemd/system/nfs-common.service being linked to /dev/null
> in debian/nfs-common.links?
Ignore. I see that statd, idmpad, and gssd have their own systemd units now.
Also a stupid question:
Why is /lib/systemd/system/nfs-common.service being linked to /dev/null
in debian/nfs-common.links?
It seems to prevent idmapd, statd, and gssd from being started if
systemd is used, unless you remove the link and forcibly "systemctl
enable nfs-common"
On Sat, 17 Dec 2016 04:54:21 +0100 =?UTF-8?Q?Rapha=c3=abl_Halimi?=
wrote:
> Please explain exactly in what way would my patch introduce
> *incompatible* changes. It's *trivial*, it only adds a single option,
> and a comment to hint that NFSv4 must be disabled in rpc.nfsd in
> addition of rpc.mount
In addition, it means NFSv2 cannot be enabled, since the latest rpc.nfsd
seems to have NFSv2 disabled, and there is no way to pass "-V 2" to
rpc.nfsd
Please accept the patch.
This should probably be merged with 738063
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738063
No, this is not fix
This bug is still not fixed.
In addition, it doesn't appear as though "-V 2" will enable NFSv2, which seems
to
be disabled by default now.
23 matches
Mail list logo
