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:
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
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
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
At net/sunrpc/svc.c line 355 svc_pool_for_cpu(), srv->sv_nrpools can be
zero:
return >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
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
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 <n...@nyet.org> 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 automat
On Fri, 3 Feb 2017 01:55:10 -0800 Nye Liu <n...@nyet.org> 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, 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
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.
21 matches
Mail list logo