On Thu, Dec 17, 2020 at 12:21 AM Bjorn Helgaas wrote:
>
> On Wed, Dec 16, 2020 at 12:20:53PM +0100, Ian Kumlien wrote:
> > On Wed, Dec 16, 2020 at 1:08 AM Bjorn Helgaas wrote:
> > > On Tue, Dec 15, 2020 at 02:09:12PM +0100, Ian Kumlien wrote:
> > > > On Tue, Dec
On Wed, Dec 16, 2020 at 1:08 AM Bjorn Helgaas wrote:
>
> On Tue, Dec 15, 2020 at 02:09:12PM +0100, Ian Kumlien wrote:
> > On Tue, Dec 15, 2020 at 1:40 AM Bjorn Helgaas wrote:
> > >
> > > On Mon, Dec 14, 2020 at 11:56:31PM +0100, Ian Kumlien wrote:
> > >
On Tue, Dec 15, 2020 at 1:40 AM Bjorn Helgaas wrote:
>
> On Mon, Dec 14, 2020 at 11:56:31PM +0100, Ian Kumlien wrote:
> > On Mon, Dec 14, 2020 at 8:19 PM Bjorn Helgaas wrote:
>
> > > If you're interested, you could probably unload the Realtek drivers,
> >
On Mon, Dec 14, 2020 at 8:19 PM Bjorn Helgaas wrote:
>
> On Mon, Dec 14, 2020 at 04:47:32PM +0100, Ian Kumlien wrote:
> > On Mon, Dec 14, 2020 at 3:02 PM Bjorn Helgaas wrote:
> > > On Mon, Dec 14, 2020 at 10:14:18AM +0100, Ian Kumlien wrote:
> > > > On Mon, Dec
On Mon, Dec 14, 2020 at 3:02 PM Bjorn Helgaas wrote:
>
> On Mon, Dec 14, 2020 at 10:14:18AM +0100, Ian Kumlien wrote:
> > On Mon, Dec 14, 2020 at 6:44 AM Bjorn Helgaas wrote:
> > >
> > > [+cc Jesse, Tony, David, Jakub, Heiner, lists in case there's an ASPM
> &g
ce, but AFAICT the devices in that path give us
> no reason to disable L1. If I understand the spec correctly, the
> Realtek device should not be relevant to the I211 path.]
>
> On Sun, Dec 13, 2020 at 10:39:53PM +0100, Ian Kumlien wrote:
> > On Sun, Dec 13, 2020 at 12:47 AM Bjorn
On Thu, Oct 8, 2020 at 6:19 AM Kai-Heng Feng
wrote:
>
>
>
> > On Oct 7, 2020, at 21:30, Bjorn Helgaas wrote:
> >
> > On Wed, Oct 07, 2020 at 12:26:19PM +0800, Kai-Heng Feng wrote:
> >>> On Oct 6, 2020, at 03:19, Bjorn Helgaas wrote:
> >>> On Tue, Oct 06, 2020 at 02:40:32AM +0800, Kai-Heng Feng
On Wed, Oct 7, 2020 at 3:30 PM Bjorn Helgaas wrote:
>
> On Wed, Oct 07, 2020 at 12:26:19PM +0800, Kai-Heng Feng wrote:
> > > On Oct 6, 2020, at 03:19, Bjorn Helgaas wrote:
> > > On Tue, Oct 06, 2020 at 02:40:32AM +0800, Kai-Heng Feng wrote:
> > >>> On Oct 3, 2020, at 06:18, Bjorn Helgaas wrote:
On Wed, Oct 7, 2020 at 6:26 AM Kai-Heng Feng
wrote:
>
>
>
> > On Oct 6, 2020, at 03:19, Bjorn Helgaas wrote:
> >
> > [+cc Ian, who's also working on an ASPM issue]
> >
> > On Tue, Oct 06, 2020 at 02:40:32AM +0800, Kai-Heng Feng wrote:
> >>> On Oct 3, 2020, at 06:18, Bjorn Helgaas wrote:
> >>>
amp; ASPM_STATE_L1) &&
- (latency + l1_switch_latency > acceptable->l1))
- link->aspm_capable &= ~ASPM_STATE_L1;
- l1_switch_latency += 1000;
+ if (link->aspm_capable & ASPM_STATE_L1) {
+ l
On Mon, Jan 21, 2019 at 7:48 PM David Miller wrote:
>
> From: Ian Kumlien
> Date: Mon, 21 Jan 2019 16:38:11 +0100
>
> > Hi David,
> >
> > could we have your blessing to add the following patch to -stable for
> > 4.20.4:
> > commit 41d1c8839e5f8cb781cc63
id S. Miller
---
Also, do you keep your -stable queue somewhere where I can see it?
It feels like I'm stepping on toes, adding overhead and such, which is
not what i want...
On Mon, Jan 21, 2019 at 4:10 PM Greg KH wrote:
> On Mon, Jan 21, 2019 at 03:56:24PM +0100, Ian Kumlien wrote:
>
On Mon, Jan 21, 2019 at 3:47 PM Greg KH wrote:
>
> On Mon, Jan 21, 2019 at 03:44:24PM +0100, Ian Kumlien wrote:
> > Hi,
> >
> > IMHO you are missing: 41d1c8839e5f8cb781cc635f12791decee8271b7
> >
> > Which should be marked for stable, it fixes:
> > h
Hi,
IMHO you are missing: 41d1c8839e5f8cb781cc635f12791decee8271b7
Which should be marked for stable, it fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=202235
On Fri, Jan 11, 2019 at 10:35 AM Eric Dumazet wrote:
> On Thu, Jan 10, 2019 at 12:55 AM Paolo Abeni wrote:
> > On Thu, 2019-01-10 at 09:25 +0100, Ian Kumlien wrote:
>
>
> > > This works, and so does:
> > > https://marc.info/?l=linux-netdev=154696956604748=2
On Thu, Jan 10, 2019 at 6:53 AM Eric Dumazet wrote:
> On Wed, Jan 9, 2019 at 4:48 PM Ian Kumlien wrote:
> >
> > Hi,
> >
> > Just been trough ~5+ hours of bisecting and eventually actually found
> > the culprit =)
> >
> > commit fb420d5d91c1
Hi,
Just been trough ~5+ hours of bisecting and eventually actually found
the culprit =)
commit fb420d5d91c1274d5966917725e71f27ed092a85 (refs/bisect/bad)
Author: Eric Dumazet
Date: Fri Sep 28 10:28:44 2018 -0700
tcp/fq: move back to CLOCK_MONOTONIC
[--8<--]
So this might be because my
Confirmed, sending a new mail with summary etc
On Thu, Jan 10, 2019 at 1:16 AM Ian Kumlien wrote:
>
> On Wed, Jan 9, 2019 at 12:17 AM Ian Kumlien wrote:
> > On Wed, Jan 9, 2019, 00:09 Florian Fainelli
> [--8<---]
>
> >> > when looking at "git log v4.
On Wed, Jan 9, 2019 at 12:17 AM Ian Kumlien wrote:
> On Wed, Jan 9, 2019, 00:09 Florian Fainelli > > when looking at "git log v4.19...v4.20
>> > drivers/net/ethernet/intel/ixgbe/" nothing else really stands out...
>> > The machine is also running NAT for my ho
On Tue, Jan 8, 2019 at 11:51 PM Stephen Hemminger
wrote:
> On Tue, 8 Jan 2019 23:10:04 +0100
> Ian Kumlien wrote:
> > On Sun, Jan 6, 2019 at 11:21 PM Ian Kumlien wrote:
> > >
> > > [Sorry for the repost, screwed up the netdev address...]
> > >
> > &g
On Sun, Jan 6, 2019 at 11:21 PM Ian Kumlien wrote:
>
> [Sorry for the repost, screwed up the netdev address...]
>
> Hi,
>
> Switching from 4.19.x -> 4.20 resulted in DHCP not working for my VM:s.
>
> My firewall (which also runs the dhcpd) runs VM:s and it doe
[Sorry for the repost, screwed up the netdev address...]
Hi,
Switching from 4.19.x -> 4.20 resulted in DHCP not working for my VM:s.
My firewall (which also runs the dhcpd) runs VM:s and it does this by
having physical
interfaces attached to bridges - which the VM:s in turn attach to.
Since
Hi,
Switching from 4.19.x -> 4.20 resulted in DHCP not working for my VM:s.
My firewall (which also runs the dhcpd) runs VM:s and it does this by
having physical
interfaces attached to bridges - which the VM:s in turn attach to.
Since 4.20 the VM:s can't use DHCP, it's odd since the requests
No response? Should pcc_cpufreq be assumed as broken since it actually
kills machines?
Should I submit a patch that removes it?
On Tue, Nov 20, 2018 at 3:05 PM Ian Kumlien wrote:
>
> Hi,
>
> We've had this happen a few times now, pcc_cpufreq is loaded and the
> machine
No response? Should pcc_cpufreq be assumed as broken since it actually
kills machines?
Should I submit a patch that removes it?
On Tue, Nov 20, 2018 at 3:05 PM Ian Kumlien wrote:
>
> Hi,
>
> We've had this happen a few times now, pcc_cpufreq is loaded and the
> machine
Hi,
We've had this happen a few times now, pcc_cpufreq is loaded and the
machine has a LA of 33 with kworkers consuming *all CPU*
We have had this happen before, looking at it has been pushed to the
leaky-stack^tm in my mind and...
32 cores:
processor : 31
vendor_id : GenuineIntel
cpu family :
Hi,
We've had this happen a few times now, pcc_cpufreq is loaded and the
machine has a LA of 33 with kworkers consuming *all CPU*
We have had this happen before, looking at it has been pushed to the
leaky-stack^tm in my mind and...
32 cores:
processor : 31
vendor_id : GenuineIntel
cpu family :
Hi,
I just had this happen a little while ago, got different weird
deadlocks but this one actually generated a oops..
This is basic operation, a machine with 16 gb memory mainly doing NFS traffic.
I'm currently playing with RDMA for this, which is why mlx4 is included.
When the crash occurs,
Hi,
I just had this happen a little while ago, got different weird
deadlocks but this one actually generated a oops..
This is basic operation, a machine with 16 gb memory mainly doing NFS traffic.
I'm currently playing with RDMA for this, which is why mlx4 is included.
When the crash occurs,
Hi,
While restarting a docker container today we had four machines
deadlock with the following oops
If this is related to propagate_one, then nothing has changed in the
later kernels and this could still be a issue
I'm still trying to investigate what happened
This is the OCR-corrected
Hi,
While restarting a docker container today we had four machines
deadlock with the following oops
If this is related to propagate_one, then nothing has changed in the
later kernels and this could still be a issue
I'm still trying to investigate what happened
This is the OCR-corrected
80
Fixes: ab10dccb1160 ("rps: Inspect PPTP encapsulated by GRE to get flow hash")
Signed-off-by: Ian Kumlien <ian.kuml...@gmail.com>
---
net/core/flow_dissector.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/core/flow_dissector.c b/net/core/flow_disse
80
Fixes: ab10dccb1160 ("rps: Inspect PPTP encapsulated by GRE to get flow hash")
Signed-off-by: Ian Kumlien
---
net/core/flow_dissector.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index c6d8207ffa7e..
80
Fixes: ab10dccb1160 ("rps: Inspect PPTP encapsulated by GRE to get flow hash")
Signed-off-by: Ian Kumlien <ian.kuml...@gmail.com>
---
net/core/flow_dissector.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/core/flow_dissector.c b/net/core/flow_disse
80
Fixes: ab10dccb1160 ("rps: Inspect PPTP encapsulated by GRE to get flow hash")
Signed-off-by: Ian Kumlien
---
net/core/flow_dissector.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index c6d8207ffa7e..
On Mon, Jan 2, 2017 at 5:07 AM, David Miller <da...@davemloft.net> wrote:
> From: Ian Kumlien <ian.kuml...@gmail.com>
> Date: Mon, 2 Jan 2017 00:19:36 +0100
>
>> __skb_flow_dissect can be called with a skb or a data packet, either
>> can be NULL. A
On Mon, Jan 2, 2017 at 5:07 AM, David Miller wrote:
> From: Ian Kumlien
> Date: Mon, 2 Jan 2017 00:19:36 +0100
>
>> __skb_flow_dissect can be called with a skb or a data packet, either
>> can be NULL. All calls seems to have been moved to __skb_header_pointer
>> exc
00080
---
Signed-off-by: Ian Kumlien <ian.kuml...@gmail.com>
---
net/core/flow_dissector.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index c6d8207ffa7e..32e4e0158846 100644
--- a/net/core/flow_dissector.c
00080
---
Signed-off-by: Ian Kumlien
---
net/core/flow_dissector.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index c6d8207ffa7e..32e4e0158846 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
f + offset,
+sizeof(_ppp_hdr),
+data, hlen, _ppp_hdr);
if (!ppp_hdr)
goto out_bad;
Will send a patch with signed off by n' all.
On Sun, Jan 1, 2017 at 6:31 PM, Ian Kumlien <ian.kuml
f + offset,
+sizeof(_ppp_hdr),
+data, hlen, _ppp_hdr);
if (!ppp_hdr)
goto out_bad;
Will send a patch with signed off by n' all.
On Sun, Jan 1, 2017 at 6:31 PM, Ian Kumlien wrote:
>
On Fri, Dec 30, 2016 at 11:48 PM, Ian Kumlien <ian.kuml...@gmail.com> wrote:
> Hi,
>
> Been fighting with "crash" to get it to help me to analyze my crash
> dumps... This is the output from vmcore-dmesg.
>
> This is 100% reproducible...
>
> Config tha
On Fri, Dec 30, 2016 at 11:48 PM, Ian Kumlien wrote:
> Hi,
>
> Been fighting with "crash" to get it to help me to analyze my crash
> dumps... This is the output from vmcore-dmesg.
>
> This is 100% reproducible...
>
> Config that lets the connec
Hi,
Been fighting with "crash" to get it to help me to analyze my crash
dumps... This is the output from vmcore-dmesg.
This is 100% reproducible...
Config that lets the connection trough but crashes the kernel:
# CONFIG_NF_CONNTRACK_PPTP is not set
# CONFIG_NF_NAT_PPTP is not set
CONFIG_PPTP=y
Hi,
Been fighting with "crash" to get it to help me to analyze my crash
dumps... This is the output from vmcore-dmesg.
This is 100% reproducible...
Config that lets the connection trough but crashes the kernel:
# CONFIG_NF_CONNTRACK_PPTP is not set
# CONFIG_NF_NAT_PPTP is not set
CONFIG_PPTP=y
On 22 February 2016 at 01:38, Ian Kumlien <ian.kuml...@gmail.com> wrote:
> Hi,
>
> When i tried to upgrade my, soon to be, firewall to 4.5-rc5 to do some
> testing - it deadlocked almost instantly.
After bisect, the offending patch seems to be:
b16c29191dc89bd877af99a7b04ce486
On 22 February 2016 at 01:38, Ian Kumlien wrote:
> Hi,
>
> When i tried to upgrade my, soon to be, firewall to 4.5-rc5 to do some
> testing - it deadlocked almost instantly.
After bisect, the offending patch seems to be:
b16c29191dc89bd877af99a7b04ce4866728a3e0
It looks like some
Hi,
When i tried to upgrade my, soon to be, firewall to 4.5-rc5 to do some
testing - it deadlocked almost instantly.
In the photo, i started writing "root" and it keeps repeating it, like
it's in a while loop.
https://goo.gl/photos/yGhNSogJjeb2VJyu5
Trying to get better information - as in any
Hi,
When i tried to upgrade my, soon to be, firewall to 4.5-rc5 to do some
testing - it deadlocked almost instantly.
In the photo, i started writing "root" and it keeps repeating it, like
it's in a while loop.
https://goo.gl/photos/yGhNSogJjeb2VJyu5
Trying to get better information - as in any
After a few hours the machine started to spontaneously reboot.
It's back to running 4.2.5 - which works fine.
(I don't know if these messages are actually reaching lkml since it's
not showing up in the index on marc.info)
On 4 November 2015 at 10:24, Ian Kumlien wrote:
> Hi,
>
> This
Hi,
This happened when i booted linux 4.3 on a old intel machine.
Please note, it's named before "twilight" was known and it's name is
inspired by "twilight zone" since it's actually a firewall ;)
PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND
1666 root 20 0
After a few hours the machine started to spontaneously reboot.
It's back to running 4.2.5 - which works fine.
(I don't know if these messages are actually reaching lkml since it's
not showing up in the index on marc.info)
On 4 November 2015 at 10:24, Ian Kumlien <ian.kuml...@gmail.com>
Hi,
This happened when i booted linux 4.3 on a old intel machine.
Please note, it's named before "twilight" was known and it's name is
inspired by "twilight zone" since it's actually a firewall ;)
PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND
1666 root 20 0
Sending this to both netdev and kernel since i don't know if it's the
driver or the pcie AER that does something odd - the machine was
stable before 3.19 and PCIE AER.
Everything started out like i first sent to linux nics () intel:
--
And today i had some issues and wondered why things was
Sending this to both netdev and kernel since i don't know if it's the
driver or the pcie AER that does something odd - the machine was
stable before 3.19 and PCIE AER.
Everything started out like i first sent to linux nics () intel:
--
And today i had some issues and wondered why things was
Hi,
Sorry to but in like this but I'm suffering from the same kind of
deadlocks with nouveau...
The really odd thing is that i could boot some -rc6+ kernel without
problems but it hung
while playing video and then it refused to start properly again.
Anyway, to quote Maarten:
Ok that most
Hi,
Sorry to but in like this but I'm suffering from the same kind of
deadlocks with nouveau...
The really odd thing is that i could boot some -rc6+ kernel without
problems but it hung
while playing video and then it refused to start properly again.
Anyway, to quote Maarten:
Ok that most
Hi,
I have to admit that this is perhaps not the best time to write this,
late in the evening after work but... =)
A friend of mine recently started to develop things on Linux and got a
bit confused since Linux lacks PTHREAD_SCOPE_PROCESS which just about
all other OS:es seems to implement.
Hi,
I have to admit that this is perhaps not the best time to write this,
late in the evening after work but... =)
A friend of mine recently started to develop things on Linux and got a
bit confused since Linux lacks PTHREAD_SCOPE_PROCESS which just about
all other OS:es seems to implement.
On Fri, Aug 1, 2014 at 3:16 PM, Imre Deak wrote:
[--8<--]
> Ok, I see the trace of suspend/resume now, but the bug has vanished.. I
> can't see the WARN backtrace in your original report, nor the debug
> message from the above fix, that would indicate that it had fixed
> anything ("VDD left on
On Fri, Aug 1, 2014 at 3:16 PM, Imre Deak imre.d...@intel.com wrote:
[--8--]
Ok, I see the trace of suspend/resume now, but the bug has vanished.. I
can't see the WARN backtrace in your original report, nor the debug
message from the above fix, that would indicate that it had fixed
anything
On fre, 2014-07-25 at 12:28 +0300, Imre Deak wrote:
> On Thu, 2014-07-24 at 01:33 +0200, Ian Kumlien wrote:
> > Try four, now including CC lists for the intel driver...
>
> Could you give a try to the 2 patches at:
> https://patchwork.kernel.org/patch/4437061/
>
> If t
On fre, 2014-07-25 at 12:28 +0300, Imre Deak wrote:
On Thu, 2014-07-24 at 01:33 +0200, Ian Kumlien wrote:
Try four, now including CC lists for the intel driver...
Could you give a try to the 2 patches at:
https://patchwork.kernel.org/patch/4437061/
If these don't fix the issue, could you
rep indicated that there might be two more missing...)
commit 423d01e192504764d5cb59effe5da68b035a0d41
Author: Ian Kumlien
Date: Tue Jul 22 21:10:50 2014 +0200
Add intel_display_power_get before _put
When closing the lid when using 3.16-rc6 on my laptop i got
three "WA
] [81997e6c] ret_from_fork+0x7c/0xb0
[ 9064.008878] [810eca60] ?
kthread_create_on_node+0x170/0x170
[ 9064.008880] ---[ end trace 17f9738f20aec288 ]---
This fixes the cases I found for my usecase: closing and opening the
lid.
Signed-off-by: Ian Kumlien
..)
commit 423d01e192504764d5cb59effe5da68b035a0d41
Author: Ian Kumlien
Date: Tue Jul 22 21:10:50 2014 +0200
Add intel_display_power_get before _put
When closing the lid when using 3.16-rc6 on my laptop i got
three "WARN_ON" back traces.
Example:
[ 9064.0088
...)
commit 423d01e192504764d5cb59effe5da68b035a0d41
Author: Ian Kumlien
Date: Tue Jul 22 21:10:50 2014 +0200
Add intel_display_power_get before _put
When closing the lid when using 3.16-rc6 on my laptop i got
three "WARN_ON" back traces.
Example:
[ 9064.008821] WARNING: CPU: 3 PI
On tis, 2014-07-22 at 12:20 -0700, Randy Dunlap wrote:
> On 07/22/2014 12:03 PM, Ian Kumlien wrote:
> > This is a resend, try two...
> >
> > And while the fix is simple, something along the lines of:
> > diff --git a/fs/direct-io.c b/fs/direct-io.c
> > index 980
On tis, 2014-07-22 at 21:12 +0200, Richard Weinberger wrote:
> On Tue, Jul 22, 2014 at 9:03 PM, Ian Kumlien wrote:
> > This is a resend, try two...
>
> Please see "[PATCH v3] direct-io: fix uninitialized warning in
> do_direct_IO()".
That looks like a better approac
if (IS_ERR(page)) {
ret = PTR_ERR(page);
---
I however don't know if it's in the correct C standard, it compiles fine
though... (or if this is more gcc speific)
commit f94d05ce10d869c418d3271bd028fc33bfd25e6f
Author: Ian Kumlien
Date: Tue Jul 22 20:57:50 2014 +0200
(page)) {
ret = PTR_ERR(page);
---
I however don't know if it's in the correct C standard, it compiles fine
though... (or if this is more gcc speific)
commit f94d05ce10d869c418d3271bd028fc33bfd25e6f
Author: Ian Kumlien ian.kuml...@gmail.com
Date: Tue Jul 22 20:57:50 2014
On tis, 2014-07-22 at 21:12 +0200, Richard Weinberger wrote:
On Tue, Jul 22, 2014 at 9:03 PM, Ian Kumlien ian.kuml...@gmail.com wrote:
This is a resend, try two...
Please see [PATCH v3] direct-io: fix uninitialized warning in
do_direct_IO().
That looks like a better approach, couldn't
On tis, 2014-07-22 at 12:20 -0700, Randy Dunlap wrote:
On 07/22/2014 12:03 PM, Ian Kumlien wrote:
This is a resend, try two...
And while the fix is simple, something along the lines of:
diff --git a/fs/direct-io.c b/fs/direct-io.c
index 98040ba..64a8286 100644
--- a/fs/direct-io.c
? Should it be done
differently?
(This handles the close and open lid usecase, i don't know if there
are others, a grep indicated that there might be two more missing...)
commit 423d01e192504764d5cb59effe5da68b035a0d41
Author: Ian Kumlien ian.kuml...@gmail.com
Date: Tue Jul 22 21:10:50 2014 +0200
is: Is this the correct approach? Should it be done
differently?
(This handles the close and open lid usecase, i don't know if there
are others, a grep indicated that there might be two more missing...)
commit 423d01e192504764d5cb59effe5da68b035a0d41
Author: Ian Kumlien ian.kuml...@gmail.com
Date: Tue Jul 22
On ons, 2014-01-22 at 11:52 +1100, NeilBrown wrote:
> On Mon, 20 Jan 2014 19:27:18 +0100 Ian Kumlien wrote:
> > I have been unable to trip this up, so this was it!
> >
> > Tested-by: Ian Kumlien
> >
> > I hope this hits stable ASAP ;)
>
> I've push
On ons, 2014-01-22 at 11:52 +1100, NeilBrown wrote:
On Mon, 20 Jan 2014 19:27:18 +0100 Ian Kumlien ian.kuml...@gmail.com wrote:
I have been unable to trip this up, so this was it!
Tested-by: Ian Kumlien ian.kuml...@gmail.com
I hope this hits stable ASAP ;)
I've push it out into my
t; The important aspect of the patch is that it moves the "atomic_inc" of
> "sh->count" back under the protection of ->device_lock in the case when some
> other thread might be using the same 'sh'.
I have been unable to trip this up, so this was it!
Tested-by:
On mån, 2014-01-20 at 14:37 +1100, NeilBrown wrote:
> On Mon, 20 Jan 2014 01:49:17 +0100 Ian Kumlien wrote:
>
> > On mån, 2014-01-20 at 11:38 +1100, NeilBrown wrote:
> > > On Sun, 19 Jan 2014 23:00:23 +0100 Ian Kumlien
> > > wrote:
> > >
>
is that it moves the atomic_inc of
sh-count back under the protection of -device_lock in the case when some
other thread might be using the same 'sh'.
I have been unable to trip this up, so this was it!
Tested-by: Ian Kumlien ian.kuml...@gmail.com
I hope this hits stable ASAP ;)
Thanks,
NeilBrown
On mån, 2014-01-20 at 14:37 +1100, NeilBrown wrote:
On Mon, 20 Jan 2014 01:49:17 +0100 Ian Kumlien ian.kuml...@gmail.com wrote:
On mån, 2014-01-20 at 11:38 +1100, NeilBrown wrote:
On Sun, 19 Jan 2014 23:00:23 +0100 Ian Kumlien ian.kuml...@gmail.com
wrote:
Ok, so third try
On mån, 2014-01-20 at 11:38 +1100, NeilBrown wrote:
> On Sun, 19 Jan 2014 23:00:23 +0100 Ian Kumlien wrote:
>
> > Ok, so third try to actually email this...
> > ---
> >
> > Hi,
> >
> > I started testing 3.13-rc8 on another machine since t
Ok, so third try to actually email this...
---
Hi,
I started testing 3.13-rc8 on another machine since the first one seemed
to be working fine...
One spontaneous reboot later i'm not so sure ;)
Right now i captured a kernel oops in the raid code it seems...
(Also attached to avoid mangling)
Ok, so third try to actually email this...
---
Hi,
I started testing 3.13-rc8 on another machine since the first one seemed
to be working fine...
One spontaneous reboot later i'm not so sure ;)
Right now i captured a kernel oops in the raid code it seems...
(Also attached to avoid mangling)
On mån, 2014-01-20 at 11:38 +1100, NeilBrown wrote:
On Sun, 19 Jan 2014 23:00:23 +0100 Ian Kumlien ian.kuml...@gmail.com wrote:
Ok, so third try to actually email this...
---
Hi,
I started testing 3.13-rc8 on another machine since the first one seemed
to be working fine
On Fri, Nov 15, 2013 at 05:44:26PM -0500, David Miller wrote:
> From: Bjorn Helgaas
> Date: Fri, 15 Nov 2013 15:29:53 -0700
>
> > [+cc David, Eric, Alex, netdev]
> >
> > Alex reported a similar issue at
> > http://marc.info/?l=linux-netdev=138355719901790=4
>
> Fixed by:
>
> commit
Hi,
After a lot of wondering i finally tracked down the bug that was hitting
me since 3.12-rc7. Since this is a firewall I haven't actually noticed
it all the time. But when i saw that it rebooted too often, i enabled
netconsole and this is the output:
BUG: unable to handle kernel NULL pointer
Hi,
After a lot of wondering i finally tracked down the bug that was hitting
me since 3.12-rc7. Since this is a firewall I haven't actually noticed
it all the time. But when i saw that it rebooted too often, i enabled
netconsole and this is the output:
BUG: unable to handle kernel NULL pointer
On Fri, Nov 15, 2013 at 05:44:26PM -0500, David Miller wrote:
From: Bjorn Helgaas bhelg...@google.com
Date: Fri, 15 Nov 2013 15:29:53 -0700
[+cc David, Eric, Alex, netdev]
Alex reported a similar issue at
http://marc.info/?l=linux-netdevm=138355719901790w=4
Fixed by:
commit
Hi all,
I have a atl1c networking card in my laptop - it's not connected since i
use wifi instead.
After a while of uptime it seems like it goes haywire, tools are
currently reporting data transfers of ~9GB/s
ifconfig eth0
eth0: flags=4099 mtu 1500
ether 48:5b:39:5e:b0:4b txqueuelen
Hi all,
I have a atl1c networking card in my laptop - it's not connected since i
use wifi instead.
After a while of uptime it seems like it goes haywire, tools are
currently reporting data transfers of ~9GB/s
ifconfig eth0
eth0: flags=4099UP,BROADCAST,MULTICAST mtu 1500
ether
On tor, 2012-11-29 at 20:25 +0100, Borislav Petkov wrote:
> On Thu, Nov 29, 2012 at 05:24:03PM +0100, Ian Kumlien wrote:
> > > Can you do:
> > >
> > > make arch/x86/kernel/ptrace.lst
> > >
> > > and send me that file, privately is f
On Thu, Nov 29, 2012 at 03:22:20PM +0100, Borislav Petkov wrote:
> On Thu, Nov 29, 2012 at 01:27:08PM +0100, Ian Kumlien wrote:
> > I think that chrome does traceing all the time as a part of it's
> > sandbox - this is most likely chrome monitoring flash...
>
> Ah, ok.
[
On Thu, Nov 29, 2012 at 10:26:21AM +0100, Borislav Petkov wrote:
> On Thu, Nov 29, 2012 at 12:20:02AM +0100, Ian Kumlien wrote:
> > Hi,
> >
> > Due to unexplained dns problems, I'll be using google plus to post the
> > photo of the bug output.
> >
&
On Thu, Nov 29, 2012 at 10:26:21AM +0100, Borislav Petkov wrote:
On Thu, Nov 29, 2012 at 12:20:02AM +0100, Ian Kumlien wrote:
Hi,
Due to unexplained dns problems, I'll be using google plus to post the
photo of the bug output.
https://plus.google.com/photos/110698868656495230656
On Thu, Nov 29, 2012 at 03:22:20PM +0100, Borislav Petkov wrote:
On Thu, Nov 29, 2012 at 01:27:08PM +0100, Ian Kumlien wrote:
I think that chrome does traceing all the time as a part of it's
sandbox - this is most likely chrome monitoring flash...
Ah, ok.
[ --8--8-- ]
Right, so I can
On tor, 2012-11-29 at 20:25 +0100, Borislav Petkov wrote:
On Thu, Nov 29, 2012 at 05:24:03PM +0100, Ian Kumlien wrote:
Can you do:
make arch/x86/kernel/ptrace.lst
and send me that file, privately is fine too.
Done, =)
Ok, thanks. Here it is:
8100b627: 83
these things handled ;)
--
Ian Kumlien -- http://demius.net || http://pomac.netswarm.net
signature.asc
Description: This is a digitally signed message part
these things handled ;)
--
Ian Kumlien -- http://demius.net || http://pomac.netswarm.net
signature.asc
Description: This is a digitally signed message part
From lkml:
On Tue, 27 Nov 2007 23:40:22 +0100
Ian Kumlien <[EMAIL PROTECTED]> wrote:
> [Repost, no reply has been recived]
>
> Hi,
>
> A little while ago, something went horribly wrong.
>
> I could still use my mouse and the desktop was still alive more or
> less.
1 - 100 of 154 matches
Mail list logo
