Re: Bisected: Kernel deadlock bug related to cgroups.

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

Re: Bisected: Kernel deadlock bug related to cgroups.

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

Re: Bisected: Kernel deadlock bug related to cgroups.

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: >> --

Re: Bisected: Kernel deadlock bug related to cgroups.

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: >> --

Re: Bisected: Kernel deadlock bug related to cgroups.

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

Re: Bisected: Kernel deadlock bug related to cgroups.

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

Bisected: Kernel deadlock bug related to cgroups.

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

Bisected: Kernel deadlock bug related to cgroups.

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

[PATCH 3.4 082/146] rtlwifi: rtl8192cu: Fix kernel deadlock

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

[PATCH 3.4 082/146] rtlwifi: rtl8192cu: Fix kernel deadlock

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

[PATCH 3.2 060/164] rtlwifi: rtl8192cu: Fix kernel deadlock

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.

[PATCH 3.2 060/164] rtlwifi: rtl8192cu: Fix kernel deadlock

3.2.70-rc1 review patch. If anyone has any objections, please let me know. -- From: Larry Finger larry.fin...@lwfinger.net commit 414b7e3b9ce8b0577f613e656fdbc36b34b444dd upstream. The USB mini-driver in rtlwifi, which is used by rtl8192cu, issues a call to usb_control_msg()

[PATCH 3.19.y-ckt 028/146] rtlwifi: rtl8192cu: Fix kernel deadlock

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

[PATCH 3.13.y-ckt 067/122] rtlwifi: rtl8192cu: Fix kernel deadlock

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

[PATCH 3.13.y-ckt 067/122] rtlwifi: rtl8192cu: Fix kernel deadlock

3.13.11-ckt22 -stable review patch. If anyone has any objections, please let me know. -- From: Larry Finger larry.fin...@lwfinger.net commit 414b7e3b9ce8b0577f613e656fdbc36b34b444dd upstream. The USB mini-driver in rtlwifi, which is used by rtl8192cu, issues a call to

[PATCH 3.19.y-ckt 028/146] rtlwifi: rtl8192cu: Fix kernel deadlock

3.19.8-ckt2 -stable review patch. If anyone has any objections, please let me know. -- From: Larry Finger larry.fin...@lwfinger.net commit 414b7e3b9ce8b0577f613e656fdbc36b34b444dd upstream. The USB mini-driver in rtlwifi, which is used by rtl8192cu, issues a call to

[PATCH 3.12 035/111] rtlwifi: rtl8192cu: Fix kernel deadlock

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.

[PATCH 3.12 035/111] rtlwifi: rtl8192cu: Fix kernel deadlock

From: Larry Finger larry.fin...@lwfinger.net 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()

[PATCH 3.16.y-ckt 012/110] rtlwifi: rtl8192cu: Fix kernel deadlock

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

[PATCH 3.16.y-ckt 012/110] rtlwifi: rtl8192cu: Fix kernel deadlock

3.16.7-ckt13 -stable review patch. If anyone has any objections, please let me know. -- From: Larry Finger larry.fin...@lwfinger.net commit 414b7e3b9ce8b0577f613e656fdbc36b34b444dd upstream. The USB mini-driver in rtlwifi, which is used by rtl8192cu, issues a call to

[PATCH 3.14 55/64] rtlwifi: rtl8192cu: Fix kernel deadlock

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

[PATCH 4.0 123/148] rtlwifi: rtl8192cu: Fix kernel deadlock

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.

[PATCH 3.10 42/46] rtlwifi: rtl8192cu: Fix kernel deadlock

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

[PATCH 3.10 42/46] rtlwifi: rtl8192cu: Fix kernel deadlock

3.10-stable review patch. If anyone has any objections, please let me know. -- From: Larry Finger larry.fin...@lwfinger.net commit 414b7e3b9ce8b0577f613e656fdbc36b34b444dd upstream. The USB mini-driver in rtlwifi, which is used by rtl8192cu, issues a call to usb_control_msg()

[PATCH 3.14 55/64] rtlwifi: rtl8192cu: Fix kernel deadlock

3.14-stable review patch. If anyone has any objections, please let me know. -- From: Larry Finger larry.fin...@lwfinger.net commit 414b7e3b9ce8b0577f613e656fdbc36b34b444dd upstream. The USB mini-driver in rtlwifi, which is used by rtl8192cu, issues a call to usb_control_msg()

[PATCH 4.0 123/148] rtlwifi: rtl8192cu: Fix kernel deadlock

4.0-stable review patch. If anyone has any objections, please let me know. -- From: Larry Finger larry.fin...@lwfinger.net commit 414b7e3b9ce8b0577f613e656fdbc36b34b444dd upstream. The USB mini-driver in rtlwifi, which is used by rtl8192cu, issues a call to usb_control_msg()

Re: kernel deadlock

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

Re: kernel deadlock

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

Re: kernel deadlock

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

Re: kernel deadlock

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

Re: kernel deadlock

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

Re: kernel deadlock

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

Re: kernel deadlock

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

Re: kernel deadlock

* 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

Re: kernel deadlock

* John Stultz john.stu...@linaro.org 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

Re: kernel deadlock

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

Re: kernel deadlock

On Tue, Sep 10, 2013 at 4:29 AM, John Stultz john.stu...@linaro.org 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

Re: kernel deadlock

On 09/10/2013 12:29 AM, Ingo Molnar wrote: * John Stultz john.stu...@linaro.org 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!

Re: kernel deadlock

On 09/10/2013 01:59 AM, Lin Ming wrote: On Tue, Sep 10, 2013 at 4:29 AM, John Stultz john.stu...@linaro.org 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

Re: kernel deadlock

On Wed, Sep 11, 2013 at 12:38 AM, John Stultz john.stu...@linaro.org wrote: On 09/10/2013 01:59 AM, Lin Ming wrote: On Tue, Sep 10, 2013 at 4:29 AM, John Stultz john.stu...@linaro.org wrote: [snip] So I think I've managed to finally reproduce this and hunt it down. With Peter's sched: Fix

Re: kernel deadlock

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

Re: kernel deadlock

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

Re: kernel deadlock

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

Re: kernel deadlock

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 should make the

Re: kernel deadlock

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

Re: kernel deadlock

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

Re: kernel deadlock

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

Re: kernel deadlock

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

Re: kernel deadlock

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

Re: kernel deadlock

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 enabled:

Re: kernel deadlock

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:

Re: kernel deadlock

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

Re: kernel deadlock

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

Re: kernel deadlock

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. >>>

Re: kernel deadlock

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

Re: kernel deadlock

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

Re: kernel deadlock

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, on my latest

Re: kernel deadlock

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 deadlock situation reported at

Re: kernel deadlock

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. > >

kernel deadlock

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

kernel deadlock

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

Re: kernel deadlock

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. Once I

Re: [PATCH v3.10-rc7] net: fix kernel deadlock with interface rename and netdev name retrieval.

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

Re: [PATCH v3.10-rc7] net: fix kernel deadlock with interface rename and netdev name retrieval.

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

[PATCH v3.10-rc7] net: fix kernel deadlock with interface rename and netdev name retrieval.

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

[PATCH v3.10-rc7] net: fix kernel deadlock with interface rename and netdev name retrieval.

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

Re: [PATCH v3.10-rc7] net: fix kernel deadlock with interface rename and netdev name retrieval.

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 in

Re: [PATCH v3.10-rc7] net: fix kernel deadlock with interface rename and netdev name retrieval.

From: Eric Dumazet eric.duma...@gmail.com 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

tulip log (2.2.17-2.2.18pre23 http-induced kernel deadlock)

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: eth0: exiting

tulip log (2.2.17-2.2.18pre23 http-induced kernel deadlock)

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: eth0: exiting