.patch.xz
Signing key fingerprint:
5BF6 7BC5 0826 72CA BB45 ACAE 587C 5ECA 5D0A 306C
All keys used for the above files and repositories can be found on the
following git repository:
git://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git
Enjoy!
Daniel
Changes from v4.19.307-rt133:
---
Daniel
On Mon, May 13, 2024 at 08:59:35AM GMT, Sebastian Andrzej Siewior wrote:
> On 2024-05-07 17:16:47 [+0200], Daniel Wagner wrote:
> > Dear RT Folks,
> >
> > This is the RT stable review cycle of patch 4.19.312-rt134-rc3.
> >
> > Please scream at me if I messed some
://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git
Enjoy!
Daniel
Changes from v4.19.307-rt133:
Daniel Wagner (1):
Linux 4.19.312-rt134
localversion-rt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
2.44.0
v4.19.312-rt134-rc3 stable review patch.
If anyone has any objections, please let me know.
---
Signed-off-by: Daniel Wagner
---
localversion-rt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/localversion-rt b/localversion-rt
index c2c7e0fb6685..6067da4c8c99 100644
Hi Sebastian,
On Tue, May 07, 2024 at 11:54:07AM GMT, Sebastian Andrzej Siewior wrote:
> I compared mine outcome vs v4.19-rt-next and the diff at the bottom came
> out:
>
> - timer_delete_sync() used to have "#if 0" block around
> lockdep_assert_preemption_enabled() because the function is not
Hi Sebastian,
On 06.05.24 12:46, Daniel Wagner wrote:
Dear RT Folks,
This is the RT stable review cycle of patch 4.19.312-rt134-rc2.
Please scream at me if I messed something up. Please test the patches
too.
My announce script is not attaching any conflict resolve diffs
(eventually, I'll
v4.19.312-rt134-rc2 stable review patch.
If anyone has any objections, please let me know.
---
Signed-off-by: Daniel Wagner
---
localversion-rt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/localversion-rt b/localversion-rt
index c2c7e0fb6685..6067da4c8c99 100644
://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git
Enjoy!
Daniel
Changes from v4.19.307-rt133:
Daniel Wagner (1):
Linux 4.19.312-rt134
localversion-rt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
2.44.0
://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git
Enjoy!
Daniel
Changes from v4.19.307-rt133:
Daniel Wagner (1):
Linux 4.19.312-rt134
localversion-rt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
2.44.0
v4.19.312-rt134-rc1 stable review patch.
If anyone has any objections, please let me know.
---
Signed-off-by: Daniel Wagner
---
localversion-rt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/localversion-rt b/localversion-rt
index c2c7e0fb6685..6067da4c8c99 100644
Hello RT-list!
I'm pleased to announce the 4.19.307-rt133 stable release. This is
just an update to the stable release 4.19.307. No RT specific changes.
You can get this release via the git tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git
branch: v4.19-rt
://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git
Enjoy!
Daniel
Changes from v4.19.306-rt132:
Daniel Wagner (1):
Linux 4.19.307-rt133
localversion-rt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
2.43.2
v4.19.307-rt133-rc1 stable review patch.
If anyone has any objections, please let me know.
---
Signed-off-by: Daniel Wagner
---
localversion-rt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/localversion-rt b/localversion-rt
index ecff281e807f..c2c7e0fb6685 100644
from v4.19.302-rt131:
---
Daniel Wagner (1):
Linux 4.19.306-rt132
---
localversion-rt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
---
diff --git a/localversion-rt b/localversion-rt
index a328b97369c2..ecff281e807f 100644
--- a/localversion-rt
+++ b/localversion-rt
@@ -1 +1 @@
--rt131
+-rt132
Dear RT Folks,
This is the RT stable review cycle of patch 4.19.306-rt132-rc1.
I reverted one -rt specific commit to be able to merge the 4.19.306
release:
0cb152421350 ("crypto: scompress - serialize RT percpu scratch buffer access
with a local lock")
because the stable backport
This reverts commit 0cb152421350004d4dcf3a4523d88c002d0a7973.
The stable backport f8f261f9ade2 ("crypto: scompress - Use per-CPU
struct instead multiple variables") replaces this downstream workaround.
Signed-off-by: Daniel Wagner
---
crypto/scompress.c | 6 ++
1 file changed, 2
Hello RT-list!
I'm pleased to announce the 4.19.302-rt131 stable release.
This is just an update to the v4.19.302 stable release. No RT specific
changes.
You can get this release via the git tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git
branch: v4.19-rt
v4.19.302-rt131-rc1 stable review patch.
If anyone has any objections, please let me know.
---
Signed-off-by: Daniel Wagner
---
localversion-rt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/localversion-rt b/localversion-rt
index 6fa797e5b850..a328b97369c2 100644
://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git
Enjoy!
Daniel
Changes from v4.19.299-rt130:
Daniel Wagner (1):
Linux 4.19.302-rt131
localversion-rt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
2.43.0
5BF6 7BC5 0826 72CA BB45 ACAE 587C 5ECA 5D0A 306C
All keys used for the above files and repositories can be found on the
following git repository:
git://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git
Enjoy!
Daniel
Changes from v4.19.295-rt129:
---
Daniel Wagner (2):
Revert "sc
definition (compiler
complains with conflicting definition). Thus we don't need this
backported functions and can avoid the conflict by just dropping the
backport.
Signed-off-by: Daniel Wagner
---
include/linux/preempt.h | 30 --
1 file changed, 30 deletions(-)
diff --git
://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git
Enjoy!
Daniel
Changes from v4.19.295-rt129:
Daniel Wagner (2):
Revert "sched/rt: Provide migrate_disable/enable() inlines"
Linux 4.19.299-rt130
include/linux/preempt.h | 30 --
localversion-rt | 2 +-
2 files
v4.19.299-rt130-rc1 stable review patch.
If anyone has any objections, please let me know.
---
Signed-off-by: Daniel Wagner
---
localversion-rt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/localversion-rt b/localversion-rt
index 90303f5aabcf..6fa797e5b850 100644
On Mon, Nov 27, 2023 at 05:50:21PM -0500, Steven Rostedt wrote:
> On Mon, 27 Nov 2023 17:41:08 -0500
> Steven Rostedt wrote:
>
> > From: "Steven Rostedt (Google)"
> >
> > A trace instance may only need to enable specific events. As the eventfs
> > directory of an instance currently creates all
Hello RT-list!
I'm pleased to announce the 4.19.295-rt129 stable release.
This is just an update to the v4.19.295 stable release. No RT
specific changes.
You can get this release via the git tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git
branch: v4.19-rt
://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git
Enjoy!
Daniel
Changes from v4.19.292-rt128:
Daniel Wagner (1):
Linux 4.19.295-rt129
localversion-rt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
2.41.0
v4.19.295-rt129-rc1 stable review patch.
If anyone has any objections, please let me know.
---
Signed-off-by: Daniel Wagner
---
localversion-rt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/localversion-rt b/localversion-rt
index 6d2a676e2033..90303f5aabcf 100644
dev/nvme0n1 /dev/ng0n1 0x1 1.07 GB / 1.07 GB512 B + 0
B nvme0
[1] https://lore.kernel.org/all/Y195nENga028PvT9@cormorant.local/
Daniel Wagner (1):
hw/nvme: Add hotplug handler to nvme bus
hw/nvme/ctrl.c | 13 +
1 file changed, 13 insertions(+)
--
2.40.0
Support attaching/detaching namespaces during runtime.
Signed-off-by: Daniel Wagner
---
hw/nvme/ctrl.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/hw/nvme/ctrl.c b/hw/nvme/ctrl.c
index ac24eeb5ed5a..7bddbc644cae 100644
--- a/hw/nvme/ctrl.c
+++ b/hw/nvme/ctrl.c
@@ -8314,6
dev/nvme0n1 /dev/ng0n1 0x1 1.07 GB / 1.07 GB512 B + 0
B nvme0
[1] https://lore.kernel.org/all/Y195nENga028PvT9@cormorant.local/
Daniel Wagner (1):
hw/nvme: Add hotplug handler to nvme bus
hw/nvme/ctrl.c | 13 +
1 file changed, 13 insertions(+)
--
2.40.0
Support attaching/detaching namespaces during runtime.
Signed-off-by: Daniel Wagner
---
hw/nvme/ctrl.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/hw/nvme/ctrl.c b/hw/nvme/ctrl.c
index ac24eeb5ed5a..7bddbc644cae 100644
--- a/hw/nvme/ctrl.c
+++ b/hw/nvme/ctrl.c
@@ -8314,6
On Tue, Oct 18, 2022 at 10:15:57AM +0200, Daniel Wagner wrote:
> On Mon, Oct 10, 2022 at 07:15:08PM +0200, Klaus Jensen wrote:
> > This is all upstream. Namespaces with 'shared=on' *should* all be
> > automatically attached to any hotplugged controller devices.
> >
On Tue, Oct 18, 2022 at 10:15:57AM +0200, Daniel Wagner wrote:
> On Mon, Oct 10, 2022 at 07:15:08PM +0200, Klaus Jensen wrote:
> > This is all upstream. Namespaces with 'shared=on' *should* all be
> > automatically attached to any hotplugged controller devices.
> >
On Mon, Oct 10, 2022 at 07:15:08PM +0200, Klaus Jensen wrote:
> This is all upstream. Namespaces with 'shared=on' *should* all be
> automatically attached to any hotplugged controller devices.
>
> With what setup is this not working for you?
Ah okay, I missed the 'shared=on' bit. Let me try
On Mon, Oct 10, 2022 at 07:15:08PM +0200, Klaus Jensen wrote:
> This is all upstream. Namespaces with 'shared=on' *should* all be
> automatically attached to any hotplugged controller devices.
>
> With what setup is this not working for you?
Ah okay, I missed the 'shared=on' bit. Let me try
On Tue, May 11, 2021 at 06:12:47PM +0200, Hannes Reinecke wrote:
> On 5/11/21 6:03 PM, Klaus Jensen wrote:
> > On May 11 16:54, Hannes Reinecke wrote:
> > > On 5/11/21 3:37 PM, Klaus Jensen wrote:
> > > > On May 11 15:12, Hannes Reinecke wrote:
> > > > > On 5/11/21 2:22 PM, Klaus Jensen wrote:
> >
On Tue, May 11, 2021 at 06:12:47PM +0200, Hannes Reinecke wrote:
> On 5/11/21 6:03 PM, Klaus Jensen wrote:
> > On May 11 16:54, Hannes Reinecke wrote:
> > > On 5/11/21 3:37 PM, Klaus Jensen wrote:
> > > > On May 11 15:12, Hannes Reinecke wrote:
> > > > > On 5/11/21 2:22 PM, Klaus Jensen wrote:
> >
On Tue, Apr 19, 2022 at 10:23:07AM +0200, Richard Weinberger wrote:
> On Tue, Apr 19, 2022 at 9:59 AM Daniel Wagner via Xenomai
> wrote:
> > What: High altitude realtime workshop 2022 edition
> > When: 2020-06-05 to 2020.06.07
>
> Whoops, old date.
> 10. June to 12.
Hellwig
Daniel Wagner
Richard Weinberger
Hi,
On Wed, Oct 20, 2021 at 11:56:49AM -0600, Jason A. Donenfeld wrote:
> Do you think you could chime in here regarding the apparent absence of
> wireguard on s390x? The thread began as a discussion of building it
> yourself there, but I'm wondering why it isn't already there, seeing
> as it's
: Handle error code at MAC address change
Dan Carpenter (1):
scsi: lpfc: Fix some error codes in debugfs
Daniel Wagner (4):
Merge tag 'v4.4.263' into v4.4-rt
Linux 4.4.263-rt220
Merge tag 'v4.4.267' into v4.4-rt
Linux 4.4.267-rt221
David Brazdil (1):
selinux
On Mon, Apr 12, 2021 at 10:04:02AM -0300, Jason Gunthorpe wrote:
> Basically the allocation of importance in the workqueue is assigning a
> worker, so pre-allocating a worker ensures the work can continue to
> progress without becoming dependent on allocations.
Ah okay, got it. I didn't really
Hi Jason,
On Mon, Apr 12, 2021 at 09:31:49AM -0300, Jason Gunthorpe wrote:
> What does early init have to do with WQ_MEM_RECLAIM?
40c17f75dfa9 ("workqueue: allow WQ_MEM_RECLAIM on early init workqueues")
Workqueues can be created early during boot before workqueue subsystem
in fully
ma/patch/5f5a1e4e90f3625cea57ffa79fc0e5bcb7efe09d.1548963371.git.sw...@opengridcomputing.com/
Signed-off-by: Daniel Wagner
---
drivers/nvme/host/core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 11fca6459812..a
sysfs_emit is the recommended API to use for formatting strings to be
returned to user space. It is equivalent to scnprintf and aware of the
PAGE_SIZE buffer size.
Suggested-by: Chaitanya Kulkarni
Signed-off-by: Daniel Wagner
---
drivers/nvme/host/core.c | 40
If there is an error we will leave the function early. So there
is no need for an else. Remove it.
Signed-off-by: Daniel Wagner
---
drivers/nvme/host/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index b94a30e7298d
Signed-off-by: Daniel Wagner
Reviewed-by: Ewan D. Milne
Reviewed-by: Sagi Grimberg
Reviewed-by: Himanshu Madhani
---
drivers/nvme/host/core.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index d2
changes since v1:
- use sysfs_emit instead sprintf
- simplify logic in nvme_ctrl_loss_tmo_store() and
nvme_ctrl_io_fail_tmo
- updated commit message (dropped wrong statement about
hard coded value)
Daniel Wagner (3):
nvme: Use sysfs_emit instead of sprintf
nvme: Remove superflues
Hi Chaitanya,
On Wed, Mar 31, 2021 at 08:34:31PM +, Chaitanya Kulkarni wrote:
> > WARNING: Symbolic permissions 'S_IRUGO | S_IWUSR' are not preferred.
> > Consider using octal permissions '0644'.
>
> For now keep the current style.
Okay, I thought so too. I am just wondering if a patch
ov
Signed-off-by: Daniel Wagner
---
This patch is against nvme-5.13
BTW, checkpatch complains with
WARNING: Symbolic permissions 'S_IRUGO | S_IWUSR' are not preferred. Consider
using octal permissions '0644'.
Is this something we want to adapt to?
drivers/nvme/host/c
Hello RT-list!
I'm pleased to announce the 4.4.262-rt219 stable release.
This is just an update to the latest stable release. No RT
specific changes.
I tried to fix the locking self failures I reported last time. As it
turns out the test setup was somehow broken. After redoing all the
test just
Hello RT-list!
I'm pleased to announce the 4.4.261-rt218 stable release, but beware
of the regressions!
This is updates v4.4-rt to the latest stable 4.4.261. This update was
pretty painfull as there were many futex/rtmutex backports.
Unfortunatly, I found out, that we have two regression which
to the system.
KERNEL[95481.571887] remove
/devices/virtual/nvme-fabrics/ctl/nvme5/nvme0c5n1 (block)
Let's suppress the uevents for GENHD_FL_HIDDEN by not enabling the
uevents at all.
Signed-off-by: Daniel Wagner
---
This version behaves in the same way as v1, that is I don't see any
Hi Sagi,
On Fri, Mar 05, 2021 at 11:57:30AM -0800, Sagi Grimberg wrote:
> Daniel, again, there is nothing specific about this to nvme-tcp,
> this is a safeguard against a funky controller (or a different
> bug that is hidden by this).
As far I can tell, the main difference between nvme-tcp and
to the system.
KERNEL[95481.571887] remove
/devices/virtual/nvme-fabrics/ctl/nvme5/nvme0c5n1 (block)
Let's suppress the uevents for GENHD_FL_HIDDEN again before calling
device_del() which will write trigger uevents.
Signed-off-by: Daniel Wagner
---
block/genhd.c | 3 +++
1 file changed, 3
-by: Daniel Wagner
---
The patch is against nmve-5.12.
I noted that nvme_tcp_process_nvme_cqe() returns EINVAL
where as the rest uses ENOENT. Looks a bit odd to me.
I've tested this with blktests.
v2:
- moved the check into a helper to avoid code duplication
- use nvme_reset_ctrl if request has
On Sat, Feb 27, 2021 at 02:19:01AM +0900, Keith Busch wrote:
> Crashing is bad, silent data corruption is worse. Is there truly no
> defense against that? If not, why should anyone rely on this?
If we receive an response for which we don't have a started request, we
know that something is wrong.
On Mon, Feb 15, 2021 at 01:29:45PM -0800, Sagi Grimberg wrote:
> Well, I think we should probably figure out why that is happening first.
I got my hands on a tcpdump trace. I've trimmed it to this:
No. Time SourceDestination Protocol
Length Info
1
On Sat, Feb 13, 2021 at 09:46:41AM +0100, Hannes Reinecke wrote:
> On 2/12/21 10:49 PM, Sagi Grimberg wrote:
> >
> > > > > blk_mq_tag_to_rq() will always return a request if the command_id is
> > > > > in the valid range. Check if the request has been started. If we
> > > > > blindly process the
blk_mq_tag_to_rq() will always return a request if the command_id is
in the valid range. Check if the request has been started. If we
blindly process the request we might double complete a request which
can be fatal.
Signed-off-by: Daniel Wagner
---
This patch is against nvme-5.12
me/hwmon: rework to avoid devm allocation")
Cc: Hannes Reinecke
Signed-off-by: Daniel Wagner
---
This patch is against linux-block/for-next.
drivers/nvme/host/hwmon.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/nvme/host/hwmon.c b/drivers/nvme/host/hwmon.c
index 8f9e96986780.
Hello RT-list!
I'm pleased to announce the 4.4.256-rt214 stable release.
This release is just an update to the new stable 4.4.256 version.
GregKH writes:
As was pointed out to us stable kernel maintainers last week, the
overflow of the .y release number was going to happen soon, and our
On Thu, Jan 28, 2021 at 05:18:56PM +0800, Chao Leng wrote:
> It is impossible to return NULL for nvme_next_ns(head, old).
block nvme0n1: no usable path - requeuing I/O
block nvme0n1: no usable path - requeuing I/O
block nvme0n1: no usable path - requeuing I/O
block nvme0n1: no usable path -
On Thu, Jan 28, 2021 at 09:31:30AM +0800, Chao Leng wrote:
> > --- a/drivers/nvme/host/multipath.c
> > +++ b/drivers/nvme/host/multipath.c
> > @@ -221,7 +221,7 @@ static struct nvme_ns *nvme_round_robin_path(struct
> > nvme_ns_head *head,
> > }
> > for (ns = nvme_next_ns(head, old);
> > -
t-disable section to ensure the
> request is enqueued on the same CPU as the softirq is raised.
> Some callers (USB-storage) invoke this path in preemptible context.
>
> Signed-off-by: Sebastian Andrzej Siewior
I did a quick test run with the whole series. Looks good.
Reviewed-by: Daniel Wagner
the request.
>
> Signed-off-by: Sebastian Andrzej Siewior
Reviewed-by: Daniel Wagner
nvme_round_robin_path() should test if the return ns pointer is
valid. nvme_next_ns() will return a NULL pointer if there is no path
left.
Fixes: 75c10e732724 ("nvme-multipath: round-robin I/O policy")
Cc: Hannes Reinecke
Signed-off-by: Daniel Wagner
---
v2:
- moved
On Fri, Jan 22, 2021 at 06:50:29PM +0100, Christoph Hellwig wrote:
> How can that happen once we're in the loop?
As far I can tell, it's the first nvme_next_ns() call which returns the
NULL pointer and this will pass the test 'ns != old'.
Hello RT-list!
I'm pleased to announce the 4.4.252-rt213 stable release.
This release is just an update to the new stable 4.4.252 version.
You can get this release via the git tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git
branch: v4.4-rt
Head SHA1:
nvme_round_robin_path() should test if the return ns pointer is
valid. nvme_next_ns() will return a NULL pointer if there is no path
left.
Signed-off-by: Daniel Wagner
---
drivers/nvme/host/multipath.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/nvme/host/multipath.c b/drivers
On Mon, Jan 18, 2021 at 03:49:22PM -0300, Enzo Matsumiya wrote:
> Parameter ql2xenforce_iocb_limit is enabled by default.
>
> Fixes: 89c72f4245a8 ("scsi: qla2xxx: Add IOCB resource tracking")
> Signed-off-by: Enzo Matsumiya
Reviewed-by: Daniel Wagner
On Mon, Jan 11, 2021 at 05:00:18PM +0100, Hannes Reinecke wrote:
> Yeah, using the controller node for devm allocations is quite dodgy.
> Does this one help?
>
> diff --git a/drivers/nvme/host/hwmon.c b/drivers/nvme/host/hwmon.c
> index 6fdd07fb3001..7260af028cf7 100644
> ---
On Mon, Jan 04, 2021 at 06:06:10PM -0300, Enzo Matsumiya wrote:
> @Daniel maybe try tweaking your tests to use a smaller controller
> loss timeout (-l option)? I do this on my tests because the default
> value kicks in about 30min after hot-removal -- i.e. you
> have to actually wait for the
Hello RT-list!
I'm pleased to announce the 4.4.249-rt212 stable release.
This release is just an update to the new stable 4.4.249 version and
no RT specific changes have been made.
You can get this release via the git tree at:
On Wed, Dec 30, 2020 at 04:16:53PM +0100, Daniel Wagner wrote:
> I've attached the hwmon to the nvme object, which fixes the obvious
> problem. But I still don't see any 'DEVRES REM' message. This would
> indicate the nvme object never really goes away... more debugging...
Stupid me,
On Wed, Dec 30, 2020 at 03:38:05PM +0100, Daniel Wagner wrote:
> I've enabled CONFIG_DEVRES_DEBUG and see only 'DEVRES ADD' message. If I
> read it correctly the problem is that the resource is attached to the ctl
> devm object and not for the nvme devm object.
I've attached the hwmon to
On Fri, Dec 11, 2020 at 03:12:53PM +0100, Hannes Reinecke wrote:
> So why do we have to deallocate the hwmon attributes?
> And why on reset? And who's re-creating them after reset, seeing that
> 'initialized' should be true?
nvmet: adding nsid 1 to subsystem blktests-subsystem-1
nvmet: creating
Hi Chaitanya,
On Thu, Dec 10, 2020 at 04:35:14AM +, Chaitanya Kulkarni wrote:
> Enzo,
> On 12/9/20 13:39, Enzo Matsumiya wrote:
> > Fix a possible NULL pointer dereference when trying to read
> > hwmon sysfs entries associated to NVMe-oF devices that were
> > hot-removed or disconnected.
> >
On Mon, Nov 30, 2020 at 05:17:48PM +, Christoph Hellwig wrote:
> On Mon, Nov 30, 2020 at 11:19:21AM +0100, Daniel Wagner wrote:
> > It's guaranteed that no request is in flight when a hctx is going
> > offline. This warning is only triggered when the wq's CPU is hot
> > p
On Fri, Dec 11, 2020 at 02:22:36PM -0500, Steven Rostedt wrote:
> I'm pleased to announce the 5.4.82-rt45 stable release.
>
> [ Note: There's a known issue that still needs to be fixed:
> https://lore.kernel.org/r/20201116172221.25ymeo62tgmzw...@linutronix.de
> Will be fixing this next (and
On Tue, Dec 08, 2020 at 12:04:03PM +0100, Christoph Hellwig wrote:
> can you send me details of your device mapper setup, e.g. which targets
> are used, are they used on top of whole device or partitions. Do you
> use partitions on top of the dm devices? Are any other stacking devices
>
On Mon, Nov 30, 2020 at 12:55:09PM -0800, t...@redhat.com wrote:
> From: Tom Rix
>
> The macro use will already have a semicolon.
> Remove unneeded escaped newline.
>
> Signed-off-by: Tom Rix
Reviewed-by: Daniel Wagner
> >> #define QLA_QPAIR_MARK_NOT_BUSY(__qpair) \
> >> - atomic_dec(&__qpair->ref_count);\
> >> + atomic_dec(&__qpair->ref_count) \
> > Nitpick, please insert an additional tab after the remove so that the
> > backlashes align again.
>
> How about removing the
path.
Suggested-by: Ming Lei
Signed-off-by: Daniel Wagner
---
v2:
- remove the warning as suggested by Ming
v1:
- initial version
https://lore.kernel.org/linux-block/20201126095152.19151-1-dwag...@suse.de/
block/blk-mq.c | 25 -
1 file changed, 25 deletions
On Mon, Nov 30, 2020 at 01:29:19AM -0800, Maciej Żenczykowski wrote:
> On Mon, Nov 30, 2020 at 1:23 AM Daniel Wagner wrote:
> > > #define QLA_QPAIR_MARK_NOT_BUSY(__qpair) \
> > > - atomic_dec(&__qpair->ref_count);\
> > >
Hi Tom,
On Fri, Nov 27, 2020 at 10:27:41AM -0800, t...@redhat.com wrote:
> From: Tom Rix
>
> The macro use will already have a semicolon.
>
> Signed-off-by: Tom Rix
Reviewed-by: Daniel Wagner
> ---
> drivers/scsi/qla2xxx/qla_def.h | 2 +-
> 1 file changed, 1
The current warning looks aweful like a proper crash. This is
confusing. There is not much information to gained from the stack
trace anyway, let's drop it.
While at it print the cpumask as there might be additial helpful
information when debugging the sitation.
Signed-off-by: Daniel Wagner
Hi John,
On Thu, Nov 26, 2020 at 01:20:37AM +0800, John Garry wrote:
> + activated = irqd_is_activated(>irq_data);
> + if (activated)
> + irq_domain_deactivate_irq(>irq_data);
> +
> + if (affinity->is_managed) {
> + irqd_set(>irq_data, IRQD_AFFINITY_MANAGED);
>
Hello RT-list!
I'm pleased to announce the 4.4.245-rt211 stable release.
This release is just an update to the new stable 4.4.245 version
and no RT specific changes have been made.
You can get this release via the git tree at:
Hello RT-list!
I'm pleased to announce the 4.4.244-rt210 stable release.
This release is just an update to the new stable 4.4.244 version
and no RT specific changes have been made.
You can get this release via the git tree at:
On Tue, Nov 10, 2020 at 07:05:18PM +0100, Sebastian Andrzej Siewior wrote:
> On 2020-11-09 15:37:03 [+0100], Daniel Wagner wrote:
> > > I've been staring at the code of signaltest on Friday and I might need
> > > to stare longer to figure out what it does.
> >
>
Sorry for the late response, I had to reinstall my system after a FS
corruption...
On Mon, Nov 09, 2020 at 05:31:43PM +0100, Sebastian Andrzej Siewior wrote:
> > These test run only very short with hackbench as worlkload (5 minutes).
> > Though I running these tests now for more than year with
On Mon, Nov 09, 2020 at 01:47:18PM +0100, Sebastian Andrzej Siewior wrote:
> So it is the new migrate-disable code? If you have stable 100us you
> should be able bisect it within the few commits between rt13 and rt14.
Okay, I'll start a bissect in this range.
> this looks odd. So rt1 has 415,
On Fri, Nov 06, 2020 at 11:54:47AM +0100, Sebastian Andrzej Siewior wrote:
> > rpi3signaltest 5.9.0-rc8-rt12
> > 813 0_signaltest t0-max-latency : fail 214.00
> > rpi3signaltest 5.9.0-rc8-rt12
> > 874 0_signaltest t0-max-latency : fail
On Wed, Nov 04, 2020 at 02:09:30PM +0100, Sebastian Andrzej Siewior wrote:
> Could you figure out if the arm64 thingy started with -rt4 or was
> already in rt3?
I wrote a quick and dirty script to extract the data from my logs to see
if the regression might be older then I remembered. I filtered
On Wed, Nov 04, 2020 at 12:19:48PM +0100, Daniel Wagner wrote:
> Yes, Just fired up signaltest 5 times for arm64 and x86_64 with the
> latest release. Keep you posted.
arm64
1184 0_signaltest t0-max-latency : fail 386.00
1185 0_signaltest t0-max-latency
On Wed, Nov 04, 2020 at 11:46:17AM +0100, Sebastian Andrzej Siewior wrote:
> How reproducible are these numbers? If these numbers increase between
> rt3 and rt4 then we have a hand full patches to look at.
Usually signaltest generated reproducible results.
I did see those higher numbers also for
On Tue, Nov 03, 2020 at 08:57:31PM +0100, Sebastian Andrzej Siewior wrote:
> I'm pleased to announce the v5.10-rc2-rt4 patch set.
All tests on passed in my lab. On arm64 and arm I saw slightly higher
max latency values for signaltest and sigwaittest. Usually they are
below 200us but currently I
On Tue, Oct 27, 2020 at 11:34:11AM +0100, Daniel Wagner wrote:
> It says so, let me double check if those task really run with SCHED_FIFO.
I just got an RCU stall without any background load. Anyway, just for
completeness here is the ps output:
root@c2d:~# ps -eLo pid,tid,class,rtprio,ni,pri,
On Tue, Oct 27, 2020 at 11:28:51AM +0100, Sebastian Andrzej Siewior wrote:
> Is it running as a RT task?
root@c2d:~/rt-tests# ./pi_stress
Starting PI Stress Test
Number of thread groups: 1
Duration of test run: infinite
Number of inversions per group: unlimited
Admin thread SCHED_FIFO
1 - 100 of 5390 matches
Mail list logo
