On 08/31/2016 03:33 AM, Balbir Singh wrote:
On 31/08/16 20:16, Oleg Nesterov wrote:
On 08/30, Brent Lovelace wrote:
I found a kernel deadlock regression bug introduced in the 4.4 kernel.
...
I bisected to this commit id
On 31/08/16 20:16, Oleg Nesterov wrote:
> On 08/30, Brent Lovelace wrote:
>>
>> I found a kernel deadlock regression bug introduced in the 4.4 kernel.
> ...
>> I bisected to this commit id:
>> --
On 08/30, Brent Lovelace wrote:
>
> I found a kernel deadlock regression bug introduced in the 4.4 kernel.
...
> I bisected to this commit id:
> --
> commit c9e75f0492b248aeaa7af8991a6fc9a21506bc96
I found a kernel deadlock regression bug introduced in the 4.4 kernel.
This bug occurs when running an ftp send-to-self test. We used libcurl
against
a ftp server.
We are requesting to download a 45k file at about 17 times per second.
It locks
up on its own after about 5 minutes. It will
From: Larry Finger
3.4.109-rc1 review patch. If anyone has any objections, please let me know.
--
commit 414b7e3b9ce8b0577f613e656fdbc36b34b444dd upstream.
The USB mini-driver in rtlwifi, which is used by rtl8192cu, issues a call to
usb_control_msg() with a timeout value of 0
3.2.70-rc1 review patch. If anyone has any objections, please let me know.
--
From: Larry Finger
commit 414b7e3b9ce8b0577f613e656fdbc36b34b444dd upstream.
The USB mini-driver in rtlwifi, which is used by rtl8192cu, issues a call to
usb_control_msg() with a timeout value of 0.
3.19.8-ckt2 -stable review patch. If anyone has any objections, please let me
know.
--
From: Larry Finger
commit 414b7e3b9ce8b0577f613e656fdbc36b34b444dd upstream.
The USB mini-driver in rtlwifi, which is used by rtl8192cu, issues a call to
usb_control_msg() with a timeout va
3.13.11-ckt22 -stable review patch. If anyone has any objections, please let
me know.
--
From: Larry Finger
commit 414b7e3b9ce8b0577f613e656fdbc36b34b444dd upstream.
The USB mini-driver in rtlwifi, which is used by rtl8192cu, issues a call to
usb_control_msg() with a timeout
From: Larry Finger
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit 414b7e3b9ce8b0577f613e656fdbc36b34b444dd upstream.
The USB mini-driver in rtlwifi, which is used by rtl8192cu, issues a call to
usb_control_msg() with a timeout value of 0. In
3.16.7-ckt13 -stable review patch. If anyone has any objections, please let me
know.
--
From: Larry Finger
commit 414b7e3b9ce8b0577f613e656fdbc36b34b444dd upstream.
The USB mini-driver in rtlwifi, which is used by rtl8192cu, issues a call to
usb_control_msg() with a timeout v
3.14-stable review patch. If anyone has any objections, please let me know.
--
From: Larry Finger
commit 414b7e3b9ce8b0577f613e656fdbc36b34b444dd upstream.
The USB mini-driver in rtlwifi, which is used by rtl8192cu, issues a call to
usb_control_msg() with a timeout value of 0.
4.0-stable review patch. If anyone has any objections, please let me know.
--
From: Larry Finger
commit 414b7e3b9ce8b0577f613e656fdbc36b34b444dd upstream.
The USB mini-driver in rtlwifi, which is used by rtl8192cu, issues a call to
usb_control_msg() with a timeout value of 0.
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Larry Finger
commit 414b7e3b9ce8b0577f613e656fdbc36b34b444dd upstream.
The USB mini-driver in rtlwifi, which is used by rtl8192cu, issues a call to
usb_control_msg() with a timeout value of 0.
Hi Peter,
sorry for the slow response...
On 09/09/2013 12:08 PM, Peter Zijlstra wrote:
On Tue, Sep 03, 2013 at 10:26:19AM -0700, John Stultz wrote:
Enabling the SCHED_FEAT(HRTICK, true) bit tends to cause lots of issues
on the various hardware I have, tripping the lockdep warnings on various
o
On Wed, Sep 11, 2013 at 12:38 AM, John Stultz wrote:
> On 09/10/2013 01:59 AM, Lin Ming wrote:
>> On Tue, Sep 10, 2013 at 4:29 AM, John Stultz wrote:
>>
>> [snip]
>>
>>> So I think I've managed to finally reproduce this and hunt it down.
>>>
>>> With Peter's "sched: Fix HRTICK" patch and HRTICK
On 09/10/2013 01:59 AM, Lin Ming wrote:
> On Tue, Sep 10, 2013 at 4:29 AM, John Stultz wrote:
>
> [snip]
>
>> So I think I've managed to finally reproduce this and hunt it down.
>>
>> With Peter's "sched: Fix HRTICK" patch and HRTICK enabled, I found I
>> could trigger a hard hang at boot on my x
On 09/10/2013 12:29 AM, Ingo Molnar wrote:
> * John Stultz wrote:
>
>> Now, I'm still in the dark as to why HRTICK exposes this, but seems like
>> the following patch should resolve the issue (and quiets the lockdep
>> warnings in my testing). Let me know how it works for you!
>>
>> Ingo: This m
On Tue, Sep 10, 2013 at 4:29 AM, John Stultz wrote:
[snip]
>
> So I think I've managed to finally reproduce this and hunt it down.
>
> With Peter's "sched: Fix HRTICK" patch and HRTICK enabled, I found I
> could trigger a hard hang at boot on my x86_64 kvm system. sysrq didn't
> function, so I
On Mon, Sep 09, 2013 at 01:29:47PM -0700, John Stultz wrote:
> Ingo: This makes me think we really should have some lockdep smarts
> added to seqlock/seqcount structures. Is there something already
> discovered thats preventing this, or has this just not yet been tried?
The only reason this hasn't
* John Stultz wrote:
> Now, I'm still in the dark as to why HRTICK exposes this, but seems like
> the following patch should resolve the issue (and quiets the lockdep
> warnings in my testing). Let me know how it works for you!
>
> Ingo: This makes me think we really should have some lockdep
On 09/04/2013 01:11 AM, Gerlando Falauto wrote:
> Hi John,
>
> On 09/03/2013 07:26 PM, John Stultz wrote:
>> On 09/03/2013 07:57 AM, Gerlando Falauto wrote:
>>> Hi,
>>>
>>> I tried again from scratch, so let me recap the whole situation, so we
>>> can all view it from the same standpoint. This shou
On Tue, Sep 03, 2013 at 10:26:19AM -0700, John Stultz wrote:
> Enabling the SCHED_FEAT(HRTICK, true) bit tends to cause lots of issues
> on the various hardware I have, tripping the lockdep warnings on various
> other issues:
Does whatever kernel you guys are running have this commit:
---
commit
Hi John,
On 09/03/2013 07:26 PM, John Stultz wrote:
On 09/03/2013 07:57 AM, Gerlando Falauto wrote:
Hi,
I tried again from scratch, so let me recap the whole situation, so we
can all view it from the same standpoint. This should make the problem
easier to see and reproduce.
I can confirm that
On 09/03/2013 07:57 AM, Gerlando Falauto wrote:
> Hi,
>
> I tried again from scratch, so let me recap the whole situation, so we
> can all view it from the same standpoint. This should make the problem
> easier to see and reproduce.
>
> I can confirm that running a stock 3.10 kernel with HRTICK ena
Hi,
I tried again from scratch, so let me recap the whole situation, so we
can all view it from the same standpoint. This should make the problem
easier to see and reproduce.
I can confirm that running a stock 3.10 kernel with HRTICK enabled:
diff --git a/kernel/sched/features.h b/kernel/sch
Hi Stephen,
>
Just curious. Do you have this patch from 3.11 applied to your 3.10
kernel tree?
Nope, I didn't. But I applied it, and it doesn't seem to make a
difference, unfortunately. :-(
Thanks for your help anyway!
Gerlando
commit 971ee28cbd1ccd87b3164facd9359a534c1d2892
Author: Peter
On 08/30/13 16:10, John Stultz wrote:
> On 08/30/2013 04:04 PM, Gerlando Falauto wrote:
>> Hi,
>>
>> sorry, it took me a while to narrow it down...
>>
>> On 08/30/2013 01:45 AM, John Stultz wrote:
>>> On 08/29/2013 01:56 PM, Falauto, Gerlando wrote:
Hi everyone,
I ran into the deadlo
On 08/30/2013 04:04 PM, Gerlando Falauto wrote:
> Hi,
>
> sorry, it took me a while to narrow it down...
>
> On 08/30/2013 01:45 AM, John Stultz wrote:
>> On 08/29/2013 01:56 PM, Falauto, Gerlando wrote:
>>> Hi everyone,
>>>
>>> I ran into the deadlock situation reported at the bottom.
>>> Actually
Hi,
sorry, it took me a while to narrow it down...
On 08/30/2013 01:45 AM, John Stultz wrote:
On 08/29/2013 01:56 PM, Falauto, Gerlando wrote:
Hi everyone,
I ran into the deadlock situation reported at the bottom.
Actually, on my latest 3.10 kernel for some reason I don't get the
report (the
On 08/29/2013 01:56 PM, Falauto, Gerlando wrote:
> Hi everyone,
>
> I ran into the deadlock situation reported at the bottom.
> Actually, on my latest 3.10 kernel for some reason I don't get the
> report (the kernel just hangs for some reason), so it took me quite some
> time to track it down.
>
>
Hi everyone,
I ran into the deadlock situation reported at the bottom.
Actually, on my latest 3.10 kernel for some reason I don't get the
report (the kernel just hangs for some reason), so it took me quite some
time to track it down.
Once I figured the trigger to the machine hanging was adjtimex(
From: Eric Dumazet
Date: Wed, 26 Jun 2013 09:33:34 -0700
> On Wed, 2013-06-26 at 17:23 +0200, Nicolas Schichan wrote:
>> When the kernel (compiled with CONFIG_PREEMPT=n) is performing the
>> rename of a network interface, it can end up waiting for a workqueue
>> to complete. If userland is able t
On Wed, 2013-06-26 at 17:23 +0200, Nicolas Schichan wrote:
> When the kernel (compiled with CONFIG_PREEMPT=n) is performing the
> rename of a network interface, it can end up waiting for a workqueue
> to complete. If userland is able to invoke a SIOCGIFNAME ioctl or a
> SO_BINDTODEVICE getsockopt i
When the kernel (compiled with CONFIG_PREEMPT=n) is performing the
rename of a network interface, it can end up waiting for a workqueue
to complete. If userland is able to invoke a SIOCGIFNAME ioctl or a
SO_BINDTODEVICE getsockopt in between, the kernel will deadlock due to
the fact that read_seckl
ends like this after the kernel
deadlock:
Nov 29 12:54:29 turpin kernel: In tulip_rx(), entry 27 00400320.
Nov 29 12:54:29 turpin kernel: eth0: In tulip_rx(), entry 27 00400320.
Nov 29 12:54:29 turpin kernel: eth0: interrupt csr5=0xf066 new csr5=0xf066.
Nov 29 12:54:29 turpin kernel: eth
35 matches
Mail list logo