On 12.02.2013 01:54, Jonathan Nieder wrote:
> Sarah Sharp wrote:
>
>> Can you turn on CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING,
>> recompile the 3.7.5 kernel, and send me dmesg starting from the point
>> you unmount the device and then power it off?
>>
>> I'd like to keep that patch in s
On 12.02.2013 21:42, Sarah Sharp wrote:
> [..]
> I think I see the issue. Your host controller reports the Inactive
> state after a USB disconnect. My host controllers go to the RxDetect
> state on a disconnect.
>
> The patches that went into 3.8 and the stable kernels to better handle
> the Ina
On 09/22/16 19:28, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.22 release.
> There are 118 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
Greg,
did you forge
On 09/23/16 10:14, Greg Kroah-Hartman wrote:
> On Thu, Sep 22, 2016 at 09:56:28PM +0200, Holger Hoffstätte wrote:
>> did you forget to add the -net patches in stable-queue.git/tree/net-4.4
>> or are they on hold for some reason? I think they were supposed to go
>> into .22.
On Mon, 07 Sep 2015 11:41:17 +0300, Nikolay Borisov wrote:
> Hello,
>
> On one of our servers I've observed the a kernel pannic
> happening with the following backtrace:
>
> [654405.527070] BUG: unable to handle kernel paging request at
> 00028001
> [654405.527076] IP: [] kmem_cache_a
On Mon, 07 Sep 2015 14:30:49 +0300, Nikolay Borisov wrote:
> If you have the vmlinux image for the kernel you were running at the
> time, the crash occured, could you post the output of addr2line -f -e
> path/to/vmlinux 8115bd4d to see if it also fails in
> get_freepointer.
Had to rebuild
On Mon, 07 Sep 2015 11:49:12 +, Holger Hoffstätte wrote:
> On Mon, 07 Sep 2015 14:30:49 +0300, Nikolay Borisov wrote:
>
>> If you have the vmlinux image for the kernel you were running at the
>> time, the crash occured, could you post the output of addr2line -f -e
On Thu, 01 Oct 2015 06:41:46 +0200, Andre Tomt wrote:
> On 01. okt. 2015 00:37, Holger Hoffstätte wrote:
>> On Wed, 30 Sep 2015 23:59:43 +0200, Olivier Bonvalet wrote:
>>
>>> for information, I've just upgraded 6 servers from Linux 4.1.8 to Linux
>>> 4.1.9
On 10/01/15 13:29, Wolfgang Walter wrote:
> Am Dienstag, 29. September 2015, 12:48:43 schrieb Andre Tomt:
>> On 29. sep. 2015 12:21, Andre Tomt wrote:
>>> Meanwhile I'll revert both the mentioned net patches and see how it goes.
>>
>> So that blew up as well, meaning it's not any of these two patch
On 10/01/15 13:29, Eric Dumazet wrote:
> On Thu, Oct 1, 2015 at 3:59 AM, Holger Hoffstätte
> wrote:
>>
>> On Thu, 01 Oct 2015 06:41:46 +0200, Andre Tomt wrote:
>>
>>> On 01. okt. 2015 00:37, Holger Hoffstätte wrote:
>>>> On Wed, 30 Sep 2015 23:59:43
On 10/02/15 08:52, Andre Tomt wrote:
> On 01. okt. 2015 13:52, Eric Dumazet wrote:
>> On Thu, Oct 1, 2015 at 4:43 AM, Holger Hoffstätte
>> wrote:
>>> On 10/01/15 13:29, Eric Dumazet wrote:
>>
>>>> commit 83fccfc3940c4a2db90fd7e7079f5b465cd8c6af
>>
On 01/12/18 06:58, Paolo Valente wrote:
>
>
>> Il giorno 28 dic 2017, alle ore 15:00, Holger Hoffstätte
>> ha scritto:
>>
>>
>> On 12/28/17 12:19, Paolo Valente wrote:
>> (snip half a tech report ;)
>>
>> So either this or the previous pa
On Thu, 28 Dec 2017 15:00:56 +0100, Holger Hoffstätte wrote:
> On 12/28/17 12:19, Paolo Valente wrote:
> (snip half a tech report ;)
>
> So either this or the previous patch ("limit tags for writes and async I/O"
> can lead to a hard, unrecoverable hang with heavy write
On 01/08/18 20:15, Tejun Heo wrote:
> Currently, blk-mq protects only the issue path with RCU. This patch
> puts the completion path under the same RCU protection. This will be
> used to synchronize issue/completion against timeout by later patches,
> which will also add the comments.
>
> Signed
On 01/08/18 23:55, Jens Axboe wrote:
> On 1/8/18 1:15 PM, Jens Axboe wrote:
>> On 1/8/18 12:57 PM, Holger Hoffstätte wrote:
>>> On 01/08/18 20:15, Tejun Heo wrote:
>>>> Currently, blk-mq protects only the issue path with RCU. This patch
>>>> puts the com
On 01/09/18 00:27, Holger Hoffstätte wrote:
> On 01/08/18 23:55, Jens Axboe wrote:
>> the good old
>>
>> int srcu_idx = srcu_idx;
>>
>> should get the job done.
>
> (Narrator: It didn't.)
Narrator: we retract our previous statement and apologi
block/bfq-iosched.c | 3 +++
> 2 files changed, 8 insertions(+), 2 deletions(-)
Gave this a try and can't reproduce the leak anymore, so for both patches:
Tested-by: Holger Hoffstätte
cheers!
Holger
On 01/15/18 13:33, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.14 release.
> There are 118 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
Applied to 4.14.13
On 09/27/18 11:03, Greg Kroah-Hartman wrote:
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Lyude Paul
commit 3c499ea0c662e2f38aafbd4f516b08aab8cfa0e5 upstream.
As pointed out by Daniel Vetter, we should be usinng
drm_drv_uses_atomic_mod
On 09/27/18 14:37, Greg Kroah-Hartman wrote:
On Thu, Sep 27, 2018 at 12:43:33PM +0200, Holger Hoffstätte wrote:
On 09/27/18 11:03, Greg Kroah-Hartman wrote:
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Lyude Paul
commit
On 09/27/18 15:26, Holger Hoffstätte wrote:
On 09/27/18 14:37, Greg Kroah-Hartman wrote:
On Thu, Sep 27, 2018 at 12:43:33PM +0200, Holger Hoffstätte wrote:
On 09/27/18 11:03, Greg Kroah-Hartman wrote:
4.18-stable review patch. If anyone has any objections, please let me know
On 09/27/18 16:05, Sean Paul wrote:
On Thu, Sep 27, 2018 at 03:53:26PM +0200, Holger Hoffstätte wrote:
On 09/27/18 15:26, Holger Hoffstätte wrote:
On 09/27/18 14:37, Greg Kroah-Hartman wrote:
On Thu, Sep 27, 2018 at 12:43:33PM +0200, Holger Hoffstätte wrote:
On 09/27/18 11:03, Greg Kroah
On 11/11/18 11:16 PM, Greg Kroah-Hartman wrote:
4.19-stable review patch. If anyone has any objections, please let me know.
As probably expected this patch causes problems. In my case one server
can no longer load the nct6775 hwmon module, which means the fan cannot be
monitored, and therefore
Hello Erik,
thanks for responding.
On 11/12/18 8:01 PM, Schmauss, Erik wrote:
As probably expected this patch causes problems. In my case one server can
no longer load the nct6775 hwmon module, which means the fan cannot be
monitored, and therefore my monitoring system promptly starts spamming
On 11/12/18 8:25 PM, Greg Kroah-Hartman wrote:
On Mon, Nov 12, 2018 at 07:30:57PM +0100, Holger Hoffstätte wrote:
On 11/11/18 11:16 PM, Greg Kroah-Hartman wrote:
4.19-stable review patch. If anyone has any objections, please let me know.
As probably expected this patch causes problems. In
On 10/16/18 19:03, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.18.15 release.
Gave this a try since I have r8169 NICs. Applied over .14 and now running
on three different machines. No observed regressions in dmesg or behaviour;
all smooth sailing.
cheers!
H
On Tue, 06 Jan 2015 12:54:43 -0500, Mikulas Patocka wrote:
> On Tue, 6 Jan 2015, Johannes Weiner wrote:
>
>> > The bug probably happened during git pull or apt-get update, though
>> > one can't be sure that these commands caused it.
>> >
>> > I see that 3.14.24 containes some fix for underflow (
On 05/22/18 16:48, Jianchao Wang wrote:
> Currently, kyber is very unfriendly with merging. kyber depends
> on ctx rq_list to do merging, however, most of time, it will not
> leave any requests in ctx rq_list. This is because even if tokens
> of one domain is used up, kyber will try to dispatch req
On 05/22/18 19:46, Jens Axboe wrote:
> On 5/22/18 10:20 AM, Jens Axboe wrote:
>> On 5/22/18 10:17 AM, Holger Hoffstätte wrote:
>>> On 05/22/18 16:48, Jianchao Wang wrote:
>>>> Currently, kyber is very unfriendly with merging. kyber depends
>>>> on ctx rq
On 2021-03-01 17:04, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.10.20 release.
Since this is a big update I gave it a try on my two older SandyBridge
server/desktop systems and a Lenovo AMD Ryzen7 laptop.
Good news: all three still humming along nicely.
Th
On 2021-03-07 17:18, Eric Valette wrote:
I have the following systematic crash at boot since 5.10.20 (.19 was ok)
This laptop has two graphic cards:
03:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Navi 14
[Radeon RX 5500/5500M / Pro 5500M] (rev c1)
07:00.0 VGA compatible con
On Sat, 18 Jan 2014 20:30:55 +0100, Daniel Exner wrote:
> I recently upgraded the Kernel from version 3.10 to latest stable
> 3.12.8, did the usual "make oldconfig" (resulting config attached).
>
> But now I noticed some _really_ low network performance.
Try: sysctl net.ipv4.tcp_limit_output_byt
On Mon, 15 Sep 2014 12:25:00 -0700, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.14.19 release.
As usual: patched, built & running fine on 3 different machines (x86_64),
clients & server with mix of old and new HW, all with Gentoo ~amd64
userland; no regress
On Sat, 28 Jun 2014 10:45:57 -0700, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.14.10 release.
Built & running fine on 3 different machines (x86_64), mix of old and new
HW, all with Gentoo ~amd64 userland. So far no regressions: graphics,
sound, btrfs, sus
On Fri, 04 Jul 2014 15:19:48 -0700, Greg Kroah-Hartman wrote:
> From: Takashi Iwai
>
> commit 8b3dfdaf0c25a584cb31d04d2574115cf2d422ab upstream.
Building on Gentoo ~amd64 with gcc 4.9.0:
LD [M] sound/pci/snd-intel8x0.o
CC [M] sound/pci/hda/patch_sigmatel.o
sound/pci/hda/patch_sigmatel.c:
On Fri, 04 Jul 2014 15:18:49 -0700, Greg Kroah-Hartman wrote:
> Takashi Iwai
> ALSA: hda - Adjust speaker HPF and add LED support for HP Spectre 13
Building on Gentoo ~amd64 with gcc 4.9.0 this patch (#59) fails:
LD [M] sound/pci/snd-intel8x0.o CC [M] sound/pci/hda/patch_sigmatel.o
soun
On Fri, 06 Dec 2013 13:50:50 -0800, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.12.4 release.
Patch applied cleanly on top of 3.12.3. Built & runs with no problems on
both a Thinkpad T60 (x86) and two generic whiteboxes (x64, i5/i7).
No regressions noticed s
For one of my machines the new year started with a hiccup:
Jan 1 01:55:39 tux kernel: [ cut here ]
Jan 1 01:55:39 tux kernel: WARNING: CPU: 1 PID: 21725 at
kernel/workqueue.c:1587 worker_enter_idle+0xde/0x150()
Jan 1 01:55:39 tux kernel: Modules linked in: sch_fq_codel
On Wed, 03 Sep 2014 16:44:29 -0700, Greg Kroah-Hartman wrote:
> On Wed, Sep 03, 2014 at 03:04:34PM -0700, Greg Kroah-Hartman wrote:
>> This is the start of the stable review cycle for the 3.14.18 release.
>> There are 88 patches in this series, all will be posted as a response
>> to this one. If
Forwarded Message
Subject: Re: [PATCH] block: loop: fix filesystem corruption in case of aio/dio
Date: Fri, 15 Apr 2016 21:16:42 +0800
From: Ming Lei
To: Holger Hoffstätte
On Fri, Apr 15, 2016 at 8:51 PM, Holger Hoffstätte
wrote:
> (off-list since I'm likely missing s
[cc: linux-block]
On 05/12/16 22:28, gwendal grignou wrote:
> Holger Hoffstätte googlemail.com> writes:
>
>>
>> On 11/11/15 23:08, Holger Hoffstätte wrote:
>>> On 11/11/15 22:29, Jens Axboe wrote:
>>>> On 11/11/2015 08:21 AM, Holger Hoffstätte wrote:
&
ice - as is the case on e.g. tmpfs -
we assume nonrotational storage. If there is a better way to identify such
non-devices I'd love to hear them.
Signed-off-by: Holger Hoffstätte
---
drivers/block/loop.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/block/lo
On 11/11/15 22:29, Jens Axboe wrote:
> On 11/11/2015 08:21 AM, Holger Hoffstätte wrote:
>>
>> The loop driver always declares the rotational flag of its device as
>> rotational, even when the device of the mapped file is nonrotational,
>> as is the case with SSDs or
On 12/02/15 10:29, Hugh Dickins wrote:
> On Mon, 23 Nov 2015, Dmitry Vyukov wrote:
>> On Mon, Nov 9, 2015 at 9:55 AM, Dmitry Vyukov wrote:
[snip]
>>> triggers WARNING in shmem_evict_inode:
>>>
>>> [ cut here ]
>>> WARNING: CPU: 0 PID: 10442 at mm/shmem.c:625 shmem_evict_ino
On Sun, 13 Sep 2015 14:29:41 +, Alexandru Moise wrote:
> Signed-off-by: Alexandru Moise <00moses.alexande...@gmail.com>
> ---
> fs/btrfs/transaction.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
> index 8f259b3..8a8
On 11/27/15 12:20, Toralf Förster wrote:
> On 11/27/2015 12:07 PM, Filipe Manana wrote:
>> Try the following (also pasted at
>> https://friendpaste.com/5O6o1cqWqJZDIKrH1YqG7y):
>
> Doesn't apply neither against the used 4.2.6 kernel nor aginst current git
> HEAD :
>
> t44 linux # patch -p1 --dry
On Wed, 19 Nov 2014 11:44:14 -0800, Paul E. McKenney wrote:
> On Wed, Nov 19, 2014 at 09:22:35AM -0800, Greg Kroah-Hartman wrote:
>>
>> Doesn't build in 3.17 properly :(
>
> Older kernels can use rcu_note_context_switch() instead of
> rcu_note_voluntary_context_switch(), which didn't show up unt
On Wed, 12 Nov 2014 10:14:30 +0900, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.14.24 release.
Us usual: patched, built, running fine on three different machines with
Gentoo ~amd64 userland as server, desktop, laptop. No funnies so far.
thanks!
-h
--
To un
On Fri, 10 Oct 2014 09:32:45 +0200, William Dauchy wrote:
> Hi stable release team,
>
> On Wed, Oct 1, 2014 at 10:57 AM, Jiri Slaby wrote:
>> This one is special. First, it is rounded (30). Second, most of the
>> patches are performance improvements. They are coming from SUSE
>> Enterprise Linux
On 12/18/14 17:32, J. Bruce Fields wrote:
> So this is two separate tests, both failed, the only difference is that
> the tcpdump was run on the client in one case and the server in the
> other?
Exactly: client first, then I realized you'd want to look at the server-side
too.
That being said..
>
On 12/18/14 18:06, J. Bruce Fields wrote:
> Whoops, now I see, the server-side trace has the same problem, I
> just overlooked it the first time.
Excellent, so we know it's the server's fault. Really would have been odd to
not have it in the server trace.
>> ..in order to rule out a mistake on m
On 12/20/14 19:02, J. Bruce Fields wrote:
> Gah. Does this fix it?
It does! Well done. :)
Reported-by: Holger Hoffstätte
Tested-by: Holger Hoffstätte
Thanks!
Holger
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mess
On Fri, 06 Feb 2015 15:04:50 +0100, Tomas Szepe wrote:
> Unfortunately, I have to take this back. I made the conclusion too early.
> The problem appears with this patch applied, too, only perhaps later and
> with a different frequency pattern.
+1 can confirm - I also see the stack trace in quest
g
(please CC: for followups)
I just spent two hours trying to untangle a *weird* bug that I have not
seen before. It might be new to 3.18.x but I don't know for sure.
Apologies in advance for the long prelude but I figured I need to
describe the problem scenario as precisely as possible.
All this
On 12/17/14 22:22, J. Bruce Fields wrote:
> On Tue, Dec 16, 2014 at 10:19:18PM +0000, Holger Hoffstätte wrote:
>> (..oddly broken directory over NFS..)
> That doesn't sound familiar. A network trace showing the READDIR would
> be really useful. Since this is so reproducible,
On Sat, 21 Feb 2015 11:31:04 +0100, Florian Westphal wrote:
> Tomas Szepe wrote:
>> > I tried to reproduce this without success so far on my RTL8168d/8111d
>> > device.
>> > I've been running 40 parallel netperf TCP_STREAM tests (1gbit) for the
>> > last 5 hours and so far I saw no watchdog tx t
Hi,
Jens mentioned on Twitter I should post my experience here as well,
so here we go.
I've backported this series (incl. updates) to stable-4.4.x - not too
difficult, minus the NVM part which I don't need anyway - and have been
running it for the past few days without any problem whatsoever, wi
On 04/01/16 03:01, Dave Chinner wrote:
> Can you go back to your original kernel, and lower nr_requests to 8?
Sure, did that and as expected it didn't help much. Under prolonged stress
it was actually even a bit worse than writeback throttling. IMHO that's not
really surprising either, since small
On 10/08/15 18:56, Christoph Biedl wrote:
> Eric Dumazet wrote...
>
> [ commit 83fccfc3940c4a2db90fd7e7079f5b465cd8c6af ]
>
>> It definitely should help !
>
> Yesterday, I've experienced issues somewhat similar to this, but I'm
> not entirely sure:
>
> Four of five systems running 4.1.9 stopped
On Wed, 30 Sep 2015 23:59:43 +0200, Olivier Bonvalet wrote:
> for information, I've just upgraded 6 servers from Linux 4.1.8 to Linux
> 4.1.9, and have some random soft lockup. If this can help :
Congratulations! You're not the first one to get hit by this, but
you are probably the first one to g
On 1/29/19 12:34 PM, Greg Kroah-Hartman wrote:
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Camelia Groza
[ Upstream commit 3e64cf7a435ed0500e3adaa8aada2272d3ae8abc ]
Since phy driver features became a link_mode bitmap, phy drivers tha
On 1/29/19 5:05 PM, Camelia Alexandra Groza wrote:
-Original Message-
From: Holger Hoffstätte
Sent: Tuesday, January 29, 2019 17:50
To: Greg Kroah-Hartman ; linux-
ker...@vger.kernel.org
Cc: sta...@vger.kernel.org; Scott Wood ; Camelia
Alexandra Groza ; David S. Miller
; Heiner
On 1/29/19 5:33 PM, Greg Kroah-Hartman wrote:
On Tue, Jan 29, 2019 at 04:05:16PM +, Camelia Alexandra Groza wrote:
-Original Message-
From: Holger Hoffstätte
Sent: Tuesday, January 29, 2019 17:50
To: Greg Kroah-Hartman ; linux-
ker...@vger.kernel.org
Cc: sta...@vger.kernel.org
On 3/7/19 5:25 PM, Paolo Valente wrote:
Hi,
since I didn't make it to submit these ones for 5.1, let me be
early for 5.2 :)
These patches fix some bug affecting performance, reduce execution
time a little bit, and boost throughput and responsiveness.
They are meant to be applied on top of the l
On 10/02/18 15:21, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.18.12 release.
Applied over .11 and now running on three different machines.
No observed regressions in dmesg or behaviour.
cheers!
Holger
On 09/03/18 18:55, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.18.6 release.
Unfortunately this is busted. First blamed my custom patches, but as it
turns out a 100% vanilla 4.18.6 build crashes as well. Single-user starts,
but later when starting services a
On 03/17/18 19:41, Carlos Carvalho wrote:
> I've put 4.14.27 this morning in this machine and in about 2h it started
> showing null dereferences identical to the following one. There were several
> of
> them, with about 1/2h of interval. Strangely it continued to work and I saw no
> other anomalie
On 06/02/16 14:13, Stefan Priebe - Profihost AG wrote:
>
> Am 31.05.2016 um 09:31 schrieb Dave Chinner:
>> On Tue, May 31, 2016 at 08:11:42AM +0200, Stefan Priebe - Profihost AG wrote:
I'm half tempted at this point to mostly ignore this mm/ behavour
because we are moving down the path o
od to me, as far as I can imagine the possible
> behaviour of the various async parameters just from reading the code.
If it's any help I have been running with this for a few days now; regular
day-to-day work, snapshots, balancing, defrags etc. with no obvious
problems, though I haven't tried to break it with the reproducer either.
Anyway:
Tested-by: Holger Hoffstätte
cheers,
Holger
On Sun, 05 Jun 2016 14:41:36 -0700, Greg Kroah-Hartman wrote:
> 4.4-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Oliver Neukum
>
> commit 588afcc1c0e45358159090d95bf7b246fb67565f upstream.
>
> This fixes the crash reported in:
> http
On Wed, 24 Jun 2015 23:46:26 -0400, Theodore Ts'o wrote:
> ext4: set lazytime on remount if MS_LAZYTIME is set by mount
I was wondering what had happened to this bug and was about to ask, just as I
saw this. It applies cleanly to 4.1 and does the trick - just tested with
util-linux-2.16.2. My /
On Mon, 21 Sep 2015 16:08:59 +0100, Chris Clayton wrote:
> Applying the 4.2.1-rc1 patch results in a kernel that emits the messages,
> so I guess my fix-not-yet-in-4.2 theory is right.
I have been getting these forever since I switched to ext4-for-ext3,
at least since early last year - if not lon
On Tue, 02 Feb 2016 22:09:38 +0530, Ani Sinha wrote:
> kernel.org lists linux 4.4.1 as "stable" but the releases page lists
> it as a long term stable kernel. Which one is true?
Both :) 4.4.1 is the *current* stable release and will be labeled LTS
when 4.5.1 is released. It has been this way for
On 01/26/16 11:13, Chris Bainbridge wrote:
> Booting 4.5.0-rc1 with new UBSAN checker enabled:
>
> [3.859690]
>
> [3.859694] UBSAN: Undefined behaviour in fs/btrfs/inode.c:5845:10
> [3.859696] signed inte
On 5/18/20 8:14 PM, Nitin Gupta wrote:
[patch v5 :)]
I've been successfully using this in my tree and it works great, but a friend
who also uses my tree just found a bug (actually an improvement ;) due to the
change from HUGETLB_PAGE_ORDER to HPAGE_PMD_ORDER in v5.
When building with CONFIG_TR
On 2020-06-24 17:44, Vincent Guittot wrote:
Some performance regression on reaim benchmark have been raised with
commit 070f5e860ee2 ("sched/fair: Take into account runnable_avg to classify
group")
The problem comes from the init value of runnable_avg which is initialized
with max value. Thi
On 2020-06-25 11:56, Vincent Guittot wrote:
On Thu, 25 Jun 2020 at 11:24, Holger Hoffstätte
wrote:
On 2020-06-24 17:44, Vincent Guittot wrote:
Some performance regression on reaim benchmark have been raised with
commit 070f5e860ee2 ("sched/fair: Take into account runnable_avg to cla
On 2020-06-25 12:42, Holger Hoffstätte wrote:
Nevermind, it turned out to be something else after all.
I'm not entirely sure *what* exactly yet, but for some reason my loadavg
is high again for no good reason.
Sorry for the false alarm.
-h
On 2020-09-01 17:07, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.8.6 release.
This one has a bunch of things I care about, so I gave it a try
on both my server & desktop (Gentoo, x86_64). Applies & builds cleanly,
everything working fine: no spontaneous fire
On 02/16/18 16:15, Oleksandr Natalenko wrote:
> Hi, David, Eric, Neal et al.
>
> On čtvrtek 15. února 2018 21:42:26 CET Oleksandr Natalenko wrote:
>> I've faced an issue with a limited TCP bandwidth between my laptop and a
>> server in my 1 Gbps LAN while using BBR as a congestion control mechanis
On 02/16/18 17:56, Neal Cardwell wrote:
> On Fri, Feb 16, 2018 at 11:26 AM, Holger Hoffstätte
> wrote:
>>
>> BBR in general will run with lower cwnd than e.g. Cubic or others.
>> That's a feature and necessary for WAN transfers.
>
> Please note that there'
On 02/06/18 13:26, Paolo Valente wrote:
(..)
> As Oleksadr asked too, is it deadline or mq-deadline?
You can use deadline as alias as long as blk-mq is active.
This doesn't work when mq-deadline is built as a module, but that
doesn't seem to be the problem here.
>> [ 484.179292] BUG: unable to
The plot thickens!
Just as I was about to post that I didn't have any problems - because
I didn't have any - I decided to do a second test, activated bfq on my
workstation, on a hunch typed "sync" and .. the machine locked up, hard.
Rebooted, activated bfq, typed sync..sync hangs. Luckily this t
On 02/06/18 15:55, Paolo Valente wrote:
>
>
>> Il giorno 06 feb 2018, alle ore 14:40, Holger Hoffstätte
>> ha scritto:
>>
>>
>> The plot thickens!
>>
>
> Yep, the culprit seems clearer, though ...
>
>> Just as I was about to post that
On 12/05/17 06:16, Ming Lei wrote:
> On Mon, Dec 04, 2017 at 11:48:07PM +0000, Holger Hoffstätte wrote:
>> On Tue, 05 Dec 2017 06:45:08 +0800, Ming Lei wrote:
>>
>>> On Mon, Dec 04, 2017 at 03:09:20PM +, Bart Van Assche wrote:
>>>> On Sun, 2017-12-03 at 00:3
On 12/18/17 06:49, Jonathan Woithe wrote:
> Resend to netdev. LKML CCed in case anyone in the wider kernel community
> can suggest a way forward. Please CC responses if replying only to LKML.
>
> It seems that this 4+ year old regression in the r8169 driver (documented in
> this thread on netdev
On 12/28/17 12:19, Paolo Valente wrote:
(snip half a tech report ;)
So either this or the previous patch ("limit tags for writes and async I/O"
can lead to a hard, unrecoverable hang with heavy writes. Since I couldn't
log into the affected system anymore I couldn't get any stack traces, blk-mq
d
*hctx)
> out_put_device:
> put_device(&sdev->sdev_gendev);
> out:
> + if (atomic_read(&sdev->device_busy) == 0 && !scsi_device_blocked(sdev))
> + blk_mq_delay_run_hw_queue(hctx, SCSI_QUEUE_DELAY);
> return false;
> }
So just to follow up on this: with this patch I haven't encountered any
new hangs with blk-mq, regardless of medium (SSD/rotating disk) or scheduler.
I cannot speak for other hangs that may be reproducible by other means,
but for now here's my:
Tested-by: Holger Hoffstätte
cheers,
Holger
88 matches
Mail list logo
