Hi Cesare,
> But, in the meantime, doesn't the workaround of disabling blk_mq work
> for you?
I don’t know, because I have no means to trigger the bug. The three
other virtualisators I’ve upgraded at the same time did not trigger it.
My desktop machine also hits it only occasionally.
I’ve reboot
On 28/02/19 16:44, Thorsten Glaser wrote:
please do consider uploading 4.19.24 to buster/sid with some haste.
We have headless virtualisation hosts being unreachable/frozen now,
and while these are “only” development systems, this is untenable.
Like you I'm looking forward for that kernel.
But,
Hi Debian Linux kernel maintainers,
On Wed, 27 Feb 2019, Dragan Milenkovic wrote:
> > Hello Dragan, do you know if the patch was eventually included upstream and
> > possibly in which version?
>
> Hello, Cesare. It was included in 4.20.11 and 4.19.24.
please do consider uploading 4.19.24 to bust
On 2/26/19 10:11 PM, Cesare Leonardi wrote:
Hello Dragan, do you know if the patch was eventually included upstream
and possibly in which version?
Hello, Cesare. It was included in 4.20.11 and 4.19.24.
Dragan
On 2019-02-26 21:11, Cesare Leonardi wrote:
On 13/02/19 18:21, Dragan Milenkovic wrote:
This patch is already on its way to stable branches. I have tested it
and confirmed that it resolves the problem.
Hello Dragan, do you know if the patch was eventually included
upstream and possibly in whic
On 13/02/19 18:21, Dragan Milenkovic wrote:
This patch is already on its way to stable branches. I have tested it
and confirmed that it resolves the problem.
Hello Dragan, do you know if the patch was eventually included upstream
and possibly in which version?
Cesare.
severity 913119 serious
found 913119 4.19.16-1
thanks
On Wed, 13 Feb 2019, Dragan Milenkovic wrote:
> Jens Axboe has determined that the proper fix is quite different:
>
> http://git.kernel.dk/cgit/linux-block/commit/?h=for-linus&id=85bd6e61f34dffa8ec2dc75ff3c02ee7b2f1cbce
>
> This patch is alr
Processing commands for cont...@bugs.debian.org:
> severity 913119 serious
Bug #913119 [src:linux] linux-image-4.18.0-2-amd64: Hangs on lvm raid1
Severity set to 'serious' from 'normal'
> found 913119 4.19.16-1
Bug #913119 [src:linux] linux-image-4.18.0-2-amd64: Hangs on lvm raid1
Marked as found
On Tue, 12 Feb 2019 00:04:15 +0100 Cesare Leonardi
wrote:
It still has no reply but I really hope someone will backport your fix soon.
Jens Axboe has determined that the proper fix is quite different:
http://git.kernel.dk/cgit/linux-block/commit/?h=for-linus&id=85bd6e61f34dffa8ec2dc75ff3c02ee
On Tue, 5 Feb 2019 01:36:08 +0100 Dragan Milenkovic
wrote:
I have tracked the issue to this change:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/diff/block/blk-flush.c?id=344e9ffcbd1898e1dc04085564a6e05c30ea8199
Thank you very much for your deep analisys and thank you also
I have tracked the issue to this change:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/diff/block/blk-flush.c?id=344e9ffcbd1898e1dc04085564a6e05c30ea8199
The commit log message makes it seem that it is a refactoring change,
but it inverts the sign on q->elevator test. It shou
Hi,
On 11/24/18 2:19 AM, Cesare Leonardi wrote:
>
> On Sat, 24 Nov 2018 01:08:56 +0100 Hans van Kranenburg
> wrote:
>> You didn't share any part of your logging. Can you share a part of dmesg
>> logging that shows Oops in it?
>
> Here it is, attached to this message.
> Previously I didn't attac
Hi Hans!
On Sat, 24 Nov 2018 01:08:56 +0100 Hans van Kranenburg
wrote:
You didn't share any part of your logging. Can you share a part of dmesg
logging that shows Oops in it?
Here it is, attached to this message.
Previously I didn't attached it because to me it looks substantially the
same
Hi,
On 11/24/18 12:42 AM, Cesare Leonardi wrote:
> Bug still present with the new 4.18.0-3-amd64 (4.18.20-1).
>
> This morning I've tryed to boot this new kernel version, removing the
> workaround given by the following kernel parameters:
> scsi_mod.use_blk_mq=0 dm_mod.use_blk_mq=0
>
> The syste
Bug still present with the new 4.18.0-3-amd64 (4.18.20-1).
This morning I've tryed to boot this new kernel version, removing the
workaround given by the following kernel parameters:
scsi_mod.use_blk_mq=0 dm_mod.use_blk_mq=0
The system showed disk hangs in less than 5 hours, and, as in previous
I've added some details in #913138, which I believe is the same bug as
this one.
There a commenter suggested two kernel parameters that, so far, have
resolved the problem for me.
Cesare.
16 matches
Mail list logo
