smsc95xx 1-1.1:1.0 eth0: kevent 0 may have been dropped #2027
Comments
|
Interesting. The kevent dropped message occurs when the system is trying to deal with a particular scenario using kevents (using the system queue), then the scenario occurs again before the previous one has been handled. However, to get that many in the log implies that the entire processing of those messages has died completely. Usually just one every now and again. Is this repeatable? Did the TV streaming die? |
JamesH65
added
the
Waiting for external input
|
Yep it died. Probaby as en effect, not cause, of this. No network connectivity after this event. I've seen it on vanilla 4.11 and, iirc, rpi-4.9.y 4.9.27 as well.
…On May 19, 2017 4:21:40 PM GMT+02:00, James Hughes ***@***.***> wrote:
Interesting. The kevent dropped message occurs when the system is
trying to deal with a particular scenario using kevents (using the
system queue), then the scenario occurs again before the previous one
has been handled. However, to get that many in the log implies that the
entire processing of those messages has died completely. Usually just
one every now and again. Is this repeatable? Did the TV streaming die?
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#2027 (comment)
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
|
JamesH65
added
Assigned for implementation/action
and removed
Waiting for external input
|
yes, if you get that kevent dropped message, the network stack is probably FUBARd. The log seems to imply bridging is set up - can you describe how the device is set up please? |
|
Does increasing |
|
It's running 4 systemd-nspawn containers via its bridging support. I'll try the min_free_kbytes when I get back to the device end of the week. This one is fairly easily triggered. I've seen it about 6 times already this week on both .26 and .27 kernels. .17 does not have this issue, so my plan was to move upwards from that to see what triggered it. |
|
What are you running in the containers? I wonder if the CPU load of running all the containers starves the main system kevent queue of time, so the kevent required to process the ethernet packet problem isn't run in time, or whether the system queue is simply swamped with events that need processing. |
|
One containter with tvheadend, one with openhab, one with nginx, one for misc cli stuff. In terms of load, tvheadend does the most net traffic. nginx is virtually dormant, so is openhab. |
|
Hi! I just updated to rpi-4.9.33 and have had two instances like this in like 24h or so. I'd be happy to test out any patches you have... |
|
There was a fix for an issue that caused this when bridging a month back,
so it's possible you already have it. There may be further error paths that
cause it though. Did you provide a means of replication?
…On 20 Jun 2017 18:32, "andersthomson" ***@***.***> wrote:
Hi!
Any update on this? (What does 'Assigned for implementation' mean?)
I just updated to rpi-4.9.33 and have had two instances like this in like
24h or so.
I previously ran a patched (the cgroup thing) 4.9.30 which ran fine for a
couple of weeks.
I'd be happy to test out any patches you have...
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#2027 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADqrHWC9twUQRFIQFbwghVhenrULoq13ks5sGAIkgaJpZM4NgiiZ>
.
|
|
If it's in 4.9.33 I should have it. Unfortunately, I have no means to reproduce it. No idea what triggers it (last one seems to have started at 18:00 sharp, fwiw). Any chance I can sprinkle a few printfs in selected places to get more context out? |
|
Is anyone still seeing this issue? I've not seen it for a while. Wondering whether recent changes to drivers/kernel have fixed it. |
|
I'm on 4.9.33-v7+ and I'm seeing it regularly. Like once every 4 days or so. I see we're t 4.9.39 now so I should probably do an upgrade. I'll report back after that. |
|
I'll queue that after the test of 4.9.39. Last time I tested higher than 4.9 it got stuck in the userspace boot phase. My memory is failing but it was either a usb driver thing (the other driver being the default and not working ok for TV transfers??), or lvm2 stuff not being in-kernel. Any update on the usb driver side? I recall a discussion on that... |
|
Not familiar with any USB issues, or what you mean by TV transfers. I've been using 4.12 a lot, and have tried 4.13 briefly (since it has a number of driver changes for the Wifi), seems to work OK for me. |
|
Isochronous transfers. See the discussion in #1649. |
|
I guessing lots of changes in all those areas, so might be worth giving 4.13 (or 4.12) a go. |
|
Great! I'm on 4.9.33 as of this morning. I'll let that cook for a while first (and will compile a 4.13 kernel) |
|
I can report that 4.9.33 has the same issue: intermixed I now also see rcu errors. Not sure if they are related: Eg. and: |
|
OK, thanks for checking. I can only think that this might be an overloaded system queue being unable to process a kevent from the network stack before it happens again. Perhaps down to the system being very busy as it seems to be in your case. I'm not able to take any detailed look at it for the near future I'm afraid. |
|
The system hung in the middle of the night, while compiling the 4.12 kernel using make -j3 (on an usb hdd). I've also seen it hang in the middle of the night when there should be zero load. It's not overloaded in the sense of the scheduler's run queue. No TV streaming, so not much usb traffic either. The system has executed the same task for about 3 years. This error started to happen circa 4.9.15 or so. |
|
What I don't understand is why you are seeing it frequently, and others are
not.
…On 28 July 2017 at 12:18, andersthomson ***@***.***> wrote:
The system hung in the middle of the night, while compiling the 4.12
kernel using make -j3 (on an usb hdd). I've also seen it hang in the middle
of the night when there should be zero load.
It's not overloaded in the sense of the scheduler's run queue. No TV
streaming, so not much usb traffic either.
The system has executed the same task for about 3 years. This error
started to happen circa 4.9.15 or so.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_raspberrypi_linux_issues_2027-23issuecomment-2D318627217&d=DwMFaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=sWWTRAIJpDTjvEoYISFzeHvDpMeEvFwShlrUrWMGbpw&s=_oGs8Vt7ZgSpsND1P2TkOUuw6gNPJDRXLQsLzSpqiew&e=>,
or mute the thread
<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ADqrHR6lfs6X8bvYSLolCSFCAR0oeVp8ks5sScOXgaJpZM4NgiiZ&d=DwMFaQ&c=DpyQ_ftY536pf7wCBQXXU58xADDRY77THQzJu1OmzOo&r=w09_2ePv8G3zRjoV19Wm1Q6rI7CDlOns4PuRv2hHkek&m=sWWTRAIJpDTjvEoYISFzeHvDpMeEvFwShlrUrWMGbpw&s=u0Ya4dm8GlCO7wIUa1JnWvnP6WEbDQSLPb9x_Q-FVnY&e=>
.
--
James Hughes
Principal Software Engineer,
Raspberry Pi (Trading) Ltd
|
|
If that's the case, let's see what might differ:
As you can see I'm not using the dtbs stuff (whenever I try to enable it as per the net's instructions, it doesn't boot at all). I never got the hung of how the device tree stuff is expected to be used.
Quite a few kernels etc, but perhaps you can see if the initial boot files are too old or something? cat /boot/cmdline.txt Anything I should adjust in this area to become more aligned with what others might have? |
|
Not the foggiest. In Raspbian, device tree should "just work". It's been
there by default for a couple of years.
…On 28 July 2017 at 15:16, andersthomson ***@***.***> wrote:
If that's the case, let's see what might differ:
cat /boot/config.txt
#gpu_mem=192
#dtoverlay=dwc2
#device_tree=bcm2836-rpi-2-b.dtb
#device_tree=dtbs/4.9.25/bcm2836-rpi-2-b.dtb
#kernel=vmlinuz-4.9.25
#device_tree=dtbs/4.10.14/bcm2836-rpi-2-b.dtb
#kernel=vmlinuz-4.10.14
#device_tree=dtbs/4.11.1/bcm2836-rpi-2-b.dtb
#kernel=vmlinuz-4.11.1
#kernel=vmlinuz-4.9.27-v7+
#kernel=vmlinuz-4.9.21-v7-00048-g1e7deb9
#device_tree=dtbs/4.9.21-v7+/bcm2836-rpi-2-b.dtb
#kernel=vmlinuz-4.9.21-v7+
#kernel=vmlinuz-4.9.19-v7+
#kernel=vmlinuz-4.9.30-v7+
#kernel=vmlinuz-4.9.33-v7+
#device_tree=dtbs/4.9.39-v7+/bcm2836-rpi-2-b.dtb
kernel=vmlinuz-4.9.39-v7+
#kernel=kernel7-new
As you can see I'm not using the dtbs stuff (whenever I try to enable it
as per the net's instructions, it doesn't boot at all). I never got the
hung of how the device tree stuff is expected to be used.
ls -ltr /boot/
total 211092
-rwxr-xr-x 1 root root 4224800 Jan 13 2017 kernel7_orig.img
-rwxr-xr-x 1 root root 4012608 Jan 13 2017 kernel
-rwxr-xr-x 1 root root 7142324 Jan 13 2017 kernel7
-rwxr-xr-x 1 root root 3929604 Mar 13 13:11 start_x.elf
-rwxr-xr-x 1 root root 2846692
<2846692>
Mar 13 13:11 start.elf
-rwxr-xr-x 1 root root 4983140 Mar 13 13:11 start_db.elf
-rwxr-xr-x 1 root root 654980 Mar 13 13:11 start_cd.elf
-rwxr-xr-x 1 root root 1494 Mar 13 13:11 LICENCE.broadcom
-rwxr-xr-x 1 root root 4375736 Mar 13 13:11 kernel.img
-rwxr-xr-x 1 root root 4576688 Mar 13 13:11 kernel7.img
-rwxr-xr-x 1 root root 9775 Mar 13 13:11 fixup_x.dat
-rwxr-xr-x 1 root root 9777 Mar 13 13:11 fixup_db.dat
-rwxr-xr-x 1 root root 6646 Mar 13 13:11 fixup.dat
-rwxr-xr-x 1 root root 2558 Mar 13 13:11 fixup_cd.dat
-rwxr-xr-x 1 root root 18693 Mar 13 13:11 COPYING.linux
-rwxr-xr-x 1 root root 50268 Mar 13 13:11 bootcode.bin
-rwxr-xr-x 1 root root 4578440 Mar 28 14:24 kernel7-new
-rwxr-xr-x 1 root root 15660 May 1 10:22 bcm2836-rpi-2-b.dtb
-rwxr-xr-x 1 root root 14773 May 1 10:22 bcm2835-rpi-zero.dtb
-rwxr-xr-x 1 root root 15070 May 1 10:22 bcm2835-rpi-b-rev2.dtb
-rwxr-xr-x 1 root root 15194 May 1 10:22 bcm2835-rpi-b-plus.dtb
-rwxr-xr-x 1 root root 14937 May 1 10:22 bcm2835-rpi-b.dtb
-rwxr-xr-x 1 root root 14901 May 1 10:22 bcm2835-rpi-a-plus.dtb
-rwxr-xr-x 1 root root 14785 May 1 10:22 bcm2835-rpi-a.dtb
-rwxr-xr-x 1 root root 21285 May 1 10:22 bcm2710-rpi-cm3.dtb
-rwxr-xr-x 1 root root 22493 May 1 10:22 bcm2710-rpi-3-b.dtb
-rwxr-xr-x 1 root root 21402 May 1 10:22 bcm2709-rpi-2-b.dtb
-rwxr-xr-x 1 root root 19831 May 1 10:22 bcm2708-rpi-cm.dtb
-rwxr-xr-x 1 root root 20335 May 1 10:22 bcm2708-rpi-b-plus.dtb
-rwxr-xr-x 1 root root 20076 May 1 10:22 bcm2708-rpi-b.dtb
-rwxr-xr-x 1 root root 20565 May 1 10:22 bcm2708-rpi-0-w.dtb
drwxr-xr-x 2 root root 12288 May 1 10:22 overlays
-rwxr-xr-x 1 root root 4426744 May 1 11:16 vmlinuz-4.11.0-rc8+
-rwxr-xr-x 1 root root 1941138
<1941138>
May 1 11:16 System.map-4.11.0-rc8+
-rwxr-xr-x 1 root root 147224 May 1 11:16 config-4.11.0-rc8+
-rwxr-xr-x 1 root root 4513104 May 1 16:31 kernel7-test
-rwxr-xr-x 1 root root 7178384 May 3 15:06 vmlinuz-4.9.25.old
-rwxr-xr-x 1 root root 3598849 May 3 15:06 System.map-4.9.25.old
-rwxr-xr-x 1 root root 170247 May 3 15:06 config-4.9.25.old
-rwxr-xr-x 1 root root 7178584 May 3 20:34 vmlinuz-4.9.25
-rwxr-xr-x 1 root root 3598849 May 3 20:34 System.map-4.9.25
-rwxr-xr-x 1 root root 170247 May 3 20:34 config-4.9.25
-rwxr-xr-x 1 root root 7000136 May 5 14:09 vmlinuz-4.10.13.old
-rwxr-xr-x 1 root root 3696570 May 5 14:09 System.map-4.10.13.old
-rwxr-xr-x 1 root root 175546 May 5 14:09 config-4.10.13.old
-rwxr-xr-x 1 root root 6999544 May 5 15:38 vmlinuz-4.10.13
-rwxr-xr-x 1 root root 3696980 May 5 15:38 System.map-4.10.13
-rwxr-xr-x 1 root root 172988 May 5 15:38 config-4.10.13
-rwxr-xr-x 1 root root 7000760 May 5 17:07 vmlinuz-4.10.14
-rwxr-xr-x 1 root root 3697149 May 5 17:07 System.map-4.10.14
-rwxr-xr-x 1 root root 172988 May 5 17:07 config-4.10.14
-rwxr-xr-x 1 root root 7059312 May 7 20:16 vmlinuz-4.11.0
-rwxr-xr-x 1 root root 3740624 May 7 20:16 System.map-4.11.0
-rwxr-xr-x 1 root root 175603 May 7 20:16 config-4.11.0
-rwxr-xr-x 1 root root 4577560 May 15 11:37 vmlinuz-4.9.27-v7+
-rwxr-xr-x 1 root root 2222634 May 15 11:37 System.map-4.9.27-v7+
-rwxr-xr-x 1 root root 145618 May 15 11:37 config-4.9.27-v7+
-rwxr-xr-x 1 root root 7059672 May 16 09:22 vmlinuz-4.11.1.old
-rwxr-xr-x 1 root root 3740724 May 16 09:22 System.map-4.11.1.old
-rwxr-xr-x 1 root root 175603 May 16 09:22 config-4.11.1.old
-rwxr-xr-x 1 root root 7059664 May 16 14:17 vmlinuz-4.11.1
-rwxr-xr-x 1 root root 3740724 May 16 14:17 System.map-4.11.1
-rwxr-xr-x 1 root root 175603 May 16 14:17 config-4.11.1
-rwxr-xr-x 1 root root 4577488 May 19 12:56 vmlinuz-4.9.28-v7+
-rwxr-xr-x 1 root root 2222681 May 19 12:56 System.map-4.9.28-v7+
-rwxr-xr-x 1 root root 145618 May 19 12:56 config-4.9.28-v7+
-rwxr-xr-x 1 root root 4577488 May 22 07:48 vmlinuz-4.9.21-v7-00048-
g1e7deb9.old
-rwxr-xr-x 1 root root 2222681 May 22 07:48 System.map-4.9.21-v7-00048-
g1e7deb9.old
-rwxr-xr-x 1 root root 143191 May 22 07:48 config-4.9.21-v7-00048-
g1e7deb9.old
-rwxr-xr-x 1 root root 4367168
<4367168>
May 22 13:29 vmlinuz-4.9.21-v7-00048-g1e7deb9
-rwxr-xr-x 1 root root 2142164 May 22 13:29 System.map-4.9.21-v7-00048-
g1e7deb9
-rwxr-xr-x 1 root root 143191 May 22 13:29 config-4.9.21-v7-00048-g1e7deb9
-rwxr-xr-x 1 root root 4366920 May 22 14:20 vmlinuz-4.9.21-v7+
-rwxr-xr-x 1 root root 2142727 May 22 14:20 System.map-4.9.21-v7+
-rwxr-xr-x 1 root root 143132 May 22 14:20 config-4.9.21-v7+
-rwxr-xr-x 1 root root 4578584 May 28 19:47 vmlinuz-4.9.19-v7+.old
-rwxr-xr-x 1 root root 2223334 May 28 19:47 System.map-4.9.19-v7+.old
-rwxr-xr-x 1 root root 145477 May 28 19:47 config-4.9.19-v7+.old
-rwxr-xr-x 1 root root 4578232 May 28 22:00 vmlinuz-4.9.19-v7+
-rwxr-xr-x 1 root root 2223278 May 28 22:00 System.map-4.9.19-v7+
-rwxr-xr-x 1 root root 145477 May 28 22:00 config-4.9.19-v7+
-rwxr-xr-x 1 root root 4579680 May 29 20:22 vmlinuz-4.9.29-v7+
-rwxr-xr-x 1 root root 2223276 May 29 20:22 System.map-4.9.29-v7+
-rwxr-xr-x 1 root root 145581 May 29 20:22 config-4.9.29-v7+
-rwxr-xr-x 1 root root 4579832 May 31 20:24 vmlinuz-4.9.30-v7+
-rwxr-xr-x 1 root root 2223368 May 31 20:24 System.map-4.9.30-v7+
-rwxr-xr-x 1 root root 145581 May 31 20:24 config-4.9.30-v7+
-rwxr-xr-x 1 root root 192 Jun 15 20:42 cmdline.txt
-rwxr-xr-x 1 root root 4580808 Jun 19 21:52 vmlinuz-4.9.33-v7+
-rwxr-xr-x 1 root root 2223622 Jun 19 21:52 System.map-4.9.33-v7+
-rwxr-xr-x 1 root root 145630 Jun 19 21:52 config-4.9.33-v7+
-rwxr-xr-x 1 root root 4583304 Jul 26 22:27 vmlinuz-4.9.39-v7+
-rwxr-xr-x 1 root root 2224273 Jul 26 22:27 System.map-4.9.39-v7+
-rwxr-xr-x 1 root root 145662 Jul 26 22:27 config-4.9.39-v7+
drwxr-xr-x 16 root root 4096 Jul 26 22:28 dtbs
-rwxr-xr-x 1 root root 589 Jul 27 09:20 config.txt
Quite a few kernels etc, but perhaps you can see if the initial boot files
are too old or something?
cat /boot/cmdline.txt
root=/dev/mmcblk0p2 smsc95xx.turbo_mode=N rootdelay=2
console=ttyAMA0,115200 console=tty0 init=/usr/lib/systemd/systemd ro
systemd.unit=multi-user.target systemd.journald.forward_to_console=1
Anything I should adjust in this area to become more aligned with what
others might have?
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#2027 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADqrHVUnpnJwJJAyu7VNJV6eX2B6R14kks5sSe1CgaJpZM4NgiiZ>
.
--
James Hughes
Principal Software Engineer,
Raspberry Pi (Trading) Ltd
|
|
Hi,
I can report that 4.12.y have these kevent errors too.
…On July 28, 2017 5:20:47 PM GMT+02:00, James Hughes ***@***.***> wrote:
Not the foggiest. In Raspbian, device tree should "just work". It's
been
there by default for a couple of years.
On 28 July 2017 at 15:16, andersthomson ***@***.***>
wrote:
> If that's the case, let's see what might differ:
>
> cat /boot/config.txt
> #gpu_mem=192
> #dtoverlay=dwc2
> #device_tree=bcm2836-rpi-2-b.dtb
> #device_tree=dtbs/4.9.25/bcm2836-rpi-2-b.dtb
> #kernel=vmlinuz-4.9.25
> #device_tree=dtbs/4.10.14/bcm2836-rpi-2-b.dtb
> #kernel=vmlinuz-4.10.14
> #device_tree=dtbs/4.11.1/bcm2836-rpi-2-b.dtb
> #kernel=vmlinuz-4.11.1
> #kernel=vmlinuz-4.9.27-v7+
> #kernel=vmlinuz-4.9.21-v7-00048-g1e7deb9
> #device_tree=dtbs/4.9.21-v7+/bcm2836-rpi-2-b.dtb
> #kernel=vmlinuz-4.9.21-v7+
> #kernel=vmlinuz-4.9.19-v7+
> #kernel=vmlinuz-4.9.30-v7+
> #kernel=vmlinuz-4.9.33-v7+
> #device_tree=dtbs/4.9.39-v7+/bcm2836-rpi-2-b.dtb
> kernel=vmlinuz-4.9.39-v7+
> #kernel=kernel7-new
>
> As you can see I'm not using the dtbs stuff (whenever I try to enable
it
> as per the net's instructions, it doesn't boot at all). I never got
the
> hung of how the device tree stuff is expected to be used.
>
> ls -ltr /boot/
> total 211092
> -rwxr-xr-x 1 root root 4224800 Jan 13 2017 kernel7_orig.img
> -rwxr-xr-x 1 root root 4012608 Jan 13 2017 kernel
> -rwxr-xr-x 1 root root 7142324 Jan 13 2017 kernel7
> -rwxr-xr-x 1 root root 3929604 Mar 13 13:11 start_x.elf
> -rwxr-xr-x 1 root root 2846692
>
<2846692>
> Mar 13 13:11 start.elf
> -rwxr-xr-x 1 root root 4983140 Mar 13 13:11 start_db.elf
> -rwxr-xr-x 1 root root 654980 Mar 13 13:11 start_cd.elf
> -rwxr-xr-x 1 root root 1494 Mar 13 13:11 LICENCE.broadcom
> -rwxr-xr-x 1 root root 4375736 Mar 13 13:11 kernel.img
> -rwxr-xr-x 1 root root 4576688 Mar 13 13:11 kernel7.img
> -rwxr-xr-x 1 root root 9775 Mar 13 13:11 fixup_x.dat
> -rwxr-xr-x 1 root root 9777 Mar 13 13:11 fixup_db.dat
> -rwxr-xr-x 1 root root 6646 Mar 13 13:11 fixup.dat
> -rwxr-xr-x 1 root root 2558 Mar 13 13:11 fixup_cd.dat
> -rwxr-xr-x 1 root root 18693 Mar 13 13:11 COPYING.linux
> -rwxr-xr-x 1 root root 50268 Mar 13 13:11 bootcode.bin
> -rwxr-xr-x 1 root root 4578440 Mar 28 14:24 kernel7-new
> -rwxr-xr-x 1 root root 15660 May 1 10:22 bcm2836-rpi-2-b.dtb
> -rwxr-xr-x 1 root root 14773 May 1 10:22 bcm2835-rpi-zero.dtb
> -rwxr-xr-x 1 root root 15070 May 1 10:22 bcm2835-rpi-b-rev2.dtb
> -rwxr-xr-x 1 root root 15194 May 1 10:22 bcm2835-rpi-b-plus.dtb
> -rwxr-xr-x 1 root root 14937 May 1 10:22 bcm2835-rpi-b.dtb
> -rwxr-xr-x 1 root root 14901 May 1 10:22 bcm2835-rpi-a-plus.dtb
> -rwxr-xr-x 1 root root 14785 May 1 10:22 bcm2835-rpi-a.dtb
> -rwxr-xr-x 1 root root 21285 May 1 10:22 bcm2710-rpi-cm3.dtb
> -rwxr-xr-x 1 root root 22493 May 1 10:22 bcm2710-rpi-3-b.dtb
> -rwxr-xr-x 1 root root 21402 May 1 10:22 bcm2709-rpi-2-b.dtb
> -rwxr-xr-x 1 root root 19831 May 1 10:22 bcm2708-rpi-cm.dtb
> -rwxr-xr-x 1 root root 20335 May 1 10:22 bcm2708-rpi-b-plus.dtb
> -rwxr-xr-x 1 root root 20076 May 1 10:22 bcm2708-rpi-b.dtb
> -rwxr-xr-x 1 root root 20565 May 1 10:22 bcm2708-rpi-0-w.dtb
> drwxr-xr-x 2 root root 12288 May 1 10:22 overlays
> -rwxr-xr-x 1 root root 4426744 May 1 11:16 vmlinuz-4.11.0-rc8+
> -rwxr-xr-x 1 root root 1941138
>
<1941138>
> May 1 11:16 System.map-4.11.0-rc8+
> -rwxr-xr-x 1 root root 147224 May 1 11:16 config-4.11.0-rc8+
> -rwxr-xr-x 1 root root 4513104 May 1 16:31 kernel7-test
> -rwxr-xr-x 1 root root 7178384 May 3 15:06 vmlinuz-4.9.25.old
> -rwxr-xr-x 1 root root 3598849 May 3 15:06 System.map-4.9.25.old
> -rwxr-xr-x 1 root root 170247 May 3 15:06 config-4.9.25.old
> -rwxr-xr-x 1 root root 7178584 May 3 20:34 vmlinuz-4.9.25
> -rwxr-xr-x 1 root root 3598849 May 3 20:34 System.map-4.9.25
> -rwxr-xr-x 1 root root 170247 May 3 20:34 config-4.9.25
> -rwxr-xr-x 1 root root 7000136 May 5 14:09 vmlinuz-4.10.13.old
> -rwxr-xr-x 1 root root 3696570 May 5 14:09 System.map-4.10.13.old
> -rwxr-xr-x 1 root root 175546 May 5 14:09 config-4.10.13.old
> -rwxr-xr-x 1 root root 6999544 May 5 15:38 vmlinuz-4.10.13
> -rwxr-xr-x 1 root root 3696980 May 5 15:38 System.map-4.10.13
> -rwxr-xr-x 1 root root 172988 May 5 15:38 config-4.10.13
> -rwxr-xr-x 1 root root 7000760 May 5 17:07 vmlinuz-4.10.14
> -rwxr-xr-x 1 root root 3697149 May 5 17:07 System.map-4.10.14
> -rwxr-xr-x 1 root root 172988 May 5 17:07 config-4.10.14
> -rwxr-xr-x 1 root root 7059312 May 7 20:16 vmlinuz-4.11.0
> -rwxr-xr-x 1 root root 3740624 May 7 20:16 System.map-4.11.0
> -rwxr-xr-x 1 root root 175603 May 7 20:16 config-4.11.0
> -rwxr-xr-x 1 root root 4577560 May 15 11:37 vmlinuz-4.9.27-v7+
> -rwxr-xr-x 1 root root 2222634 May 15 11:37 System.map-4.9.27-v7+
> -rwxr-xr-x 1 root root 145618 May 15 11:37 config-4.9.27-v7+
> -rwxr-xr-x 1 root root 7059672 May 16 09:22 vmlinuz-4.11.1.old
> -rwxr-xr-x 1 root root 3740724 May 16 09:22 System.map-4.11.1.old
> -rwxr-xr-x 1 root root 175603 May 16 09:22 config-4.11.1.old
> -rwxr-xr-x 1 root root 7059664 May 16 14:17 vmlinuz-4.11.1
> -rwxr-xr-x 1 root root 3740724 May 16 14:17 System.map-4.11.1
> -rwxr-xr-x 1 root root 175603 May 16 14:17 config-4.11.1
> -rwxr-xr-x 1 root root 4577488 May 19 12:56 vmlinuz-4.9.28-v7+
> -rwxr-xr-x 1 root root 2222681 May 19 12:56 System.map-4.9.28-v7+
> -rwxr-xr-x 1 root root 145618 May 19 12:56 config-4.9.28-v7+
> -rwxr-xr-x 1 root root 4577488 May 22 07:48 vmlinuz-4.9.21-v7-00048-
> g1e7deb9.old
> -rwxr-xr-x 1 root root 2222681 May 22 07:48
System.map-4.9.21-v7-00048-
> g1e7deb9.old
> -rwxr-xr-x 1 root root 143191 May 22 07:48 config-4.9.21-v7-00048-
> g1e7deb9.old
> -rwxr-xr-x 1 root root 4367168
>
<4367168>
> May 22 13:29 vmlinuz-4.9.21-v7-00048-g1e7deb9
> -rwxr-xr-x 1 root root 2142164 May 22 13:29
System.map-4.9.21-v7-00048-
> g1e7deb9
> -rwxr-xr-x 1 root root 143191 May 22 13:29
config-4.9.21-v7-00048-g1e7deb9
> -rwxr-xr-x 1 root root 4366920 May 22 14:20 vmlinuz-4.9.21-v7+
> -rwxr-xr-x 1 root root 2142727 May 22 14:20 System.map-4.9.21-v7+
> -rwxr-xr-x 1 root root 143132 May 22 14:20 config-4.9.21-v7+
> -rwxr-xr-x 1 root root 4578584 May 28 19:47 vmlinuz-4.9.19-v7+.old
> -rwxr-xr-x 1 root root 2223334 May 28 19:47 System.map-4.9.19-v7+.old
> -rwxr-xr-x 1 root root 145477 May 28 19:47 config-4.9.19-v7+.old
> -rwxr-xr-x 1 root root 4578232 May 28 22:00 vmlinuz-4.9.19-v7+
> -rwxr-xr-x 1 root root 2223278 May 28 22:00 System.map-4.9.19-v7+
> -rwxr-xr-x 1 root root 145477 May 28 22:00 config-4.9.19-v7+
> -rwxr-xr-x 1 root root 4579680 May 29 20:22 vmlinuz-4.9.29-v7+
> -rwxr-xr-x 1 root root 2223276 May 29 20:22 System.map-4.9.29-v7+
> -rwxr-xr-x 1 root root 145581 May 29 20:22 config-4.9.29-v7+
> -rwxr-xr-x 1 root root 4579832 May 31 20:24 vmlinuz-4.9.30-v7+
> -rwxr-xr-x 1 root root 2223368 May 31 20:24 System.map-4.9.30-v7+
> -rwxr-xr-x 1 root root 145581 May 31 20:24 config-4.9.30-v7+
> -rwxr-xr-x 1 root root 192 Jun 15 20:42 cmdline.txt
> -rwxr-xr-x 1 root root 4580808 Jun 19 21:52 vmlinuz-4.9.33-v7+
> -rwxr-xr-x 1 root root 2223622 Jun 19 21:52 System.map-4.9.33-v7+
> -rwxr-xr-x 1 root root 145630 Jun 19 21:52 config-4.9.33-v7+
> -rwxr-xr-x 1 root root 4583304 Jul 26 22:27 vmlinuz-4.9.39-v7+
> -rwxr-xr-x 1 root root 2224273 Jul 26 22:27 System.map-4.9.39-v7+
> -rwxr-xr-x 1 root root 145662 Jul 26 22:27 config-4.9.39-v7+
> drwxr-xr-x 16 root root 4096 Jul 26 22:28 dtbs
> -rwxr-xr-x 1 root root 589 Jul 27 09:20 config.txt
>
> Quite a few kernels etc, but perhaps you can see if the initial boot
files
> are too old or something?
>
> cat /boot/cmdline.txt
> root=/dev/mmcblk0p2 smsc95xx.turbo_mode=N rootdelay=2
> console=ttyAMA0,115200 console=tty0 init=/usr/lib/systemd/systemd ro
> systemd.unit=multi-user.target systemd.journald.forward_to_console=1
>
> Anything I should adjust in this area to become more aligned with
what
> others might have?
>
> —
> You are receiving this because you were assigned.
> Reply to this email directly, view it on GitHub
>
<#2027 (comment)>,
> or mute the thread
>
<https://github.com/notifications/unsubscribe-auth/ADqrHVUnpnJwJJAyu7VNJV6eX2B6R14kks5sSe1CgaJpZM4NgiiZ>
> .
>
--
James Hughes
Principal Software Engineer,
Raspberry Pi (Trading) Ltd
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#2027 (comment)
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
|
|
I can now also report that this happens on the foundation provided 4.9.45-v7+ kernel excerpt of /boot |
|
Ok, thanks for the update. I wasn't expecting any movement on this, I've
not seen anything on the linux mailing lists and there have been no driver
changes.
…On 30 Aug 2017 18:20, "andersthomson" ***@***.***> wrote:
I can now also report that this happens on the foundation provided
4.9.45-v7+ kernel
excerpt of /boot
-rwxr-xr-x 1 root root 50248 Aug 25 11:12 bootcode.bin
-rwxr-xr-x 1 root root 6694 Aug 25 11:13 fixup.dat
-rwxr-xr-x 1 root root 2594 Aug 25 11:13 fixup_cd.dat
-rwxr-xr-x 1 root root 2868644 Aug 25 11:13 start.elf
-rwxr-xr-x 1 root root 666596 Aug 25 11:14 start_cd.elf
-rwxr-xr-x 1 root root 16523 Aug 25 12:32 bcm2709-rpi-2-b.dtb
-rwxr-xr-x 1 root root 4581760 Aug 28 14:23 kernel7.img
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#2027 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADqrHaUgYkEHpyWl512EgYWLwu5XF7Vbks5sdZm3gaJpZM4NgiiZ>
.
|
|
I've experienced this TX queue stall with the exact 'kevent' error message consistently (reproducible within several hours of heavy network load) on Odroid U3 (armv7h with smsc95xx chip) on kernel on 4.9.52, but not on 4.4.89, and not on 4.14-rc3. The issue did reproduce on this fork of 4.13 https://github.com/tobiasjakobi/linux-odroid-public . So, please do try it on 4.14-rc3 (and 4.4.89) mainline, maybe the issue will go away for you too. There is a chance that something in the .config was different across my tests (I tried to keep it mostly the same, based on exynos_defconfig), or maybe the network load was different (or weather was diffferent -- it got cooler over time and maybe smsc95 overheated, who knows), but it's been running under similar load for 2.5 days without this nasty networking stall. |
|
Moved to hardkernel/linux#317 |
|
I had to move back to 4.13 because 4.14 resulted in yet another error (https://bugzilla.kernel.org/show_bug.cgi?id=197303), and the network stalls are back. But, new information is: 'ip set link down eth0' and 'ip set link up eth0' (and adding routs with 'ip route') brings the network back up. I executed this from the serial console. But, this suggests a workaround: add a systemd service that will check for network connectivity and attempt to reset link state as above. |
|
Just an observation in @andersthomson 's config, cmdline has |
|
It's been like that the last 4 years or so, since I got the machine. Either I got it as part of the default install, or from the net somewhere. Is the default these days smsc95xx.turbo_mode=y on all Pis? Or am I better off removing this altogether? |
|
As a further note. Ever since I switched to PiF built kernels (ca 4.9.30) I've not had these issues. Maybe I should build my own again an see what might be triggering it.... |
|
I'm experiencing this on my pi3 b model running ubuntu-server 16.0.4 trying to pull docker images |
|
Interesting - this one hasn't reared its head for some time. What kernel
version are you using?
…On 19 January 2018 at 12:41, karneaud ***@***.***> wrote:
I'm experiencing this on my pi3 b model running ubuntu-server 16.0.4
trying to pull docker images
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#2027 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADqrHZHdoQZr-IScPzgttmIzI16Ej4llks5tMI2UgaJpZM4NgiiZ>
.
--
James Hughes
Principal Software Engineer,
Raspberry Pi (Trading) Ltd
|
|
@JamesH65 I have this issue on kernel 4.9.35-v7+ Is there any way to fix it? |
|
Not that I am aware of. It has become much much rarer over the last year. Worth trying the latest kernel release. |
|
Ok, have installed 4.14 kernel via rpi-update. I hope it solves this problem. |
|
Possibly related: #2447 I also saw and see this on my Pi 3 B+. Very frustrating, especially cause after more than one year this issue is still not solved... :-( |
|
Completely different drivers so not the same issue. That error messages appears when a kernel work thread is being asked to service something whilst it is already servicing the same thing - it therefor drops the request. The different kevent number means a different workload. We haven't had any reports of the kevent0 issue for over a year IIRC. |
|
Here we go again: Pi had to upload a quite big file (1,55 GB) via Ethernet to a client on the internet, which was interrupted and from that time the Pi was completely unresponsive on all network services. In the evening checked the console - system up and running. No chance to reset the ethernet (e. g. by ifdown/ifup), needed to reboot the system. |
|
@bcutter NB the issue title of "smsc95xx 1-1.1:1.0 eth0: kevent 0 may have been dropped" vs your logging lines containing "lan78xx". Different chip, different drivers, different fixes required. JamesH65 had already pointed that out to you before You also don't say what kernel version you're running. rpi-update will now be giving you a 4.19 kernel, whilst Raspbian and apt is still on 4.14. Without that we have insufficient information to do anything. The warning is due to something kicking a worker thread faster than the worker thread can respond. The majority of people aren't seeing issues, so there seems to be something about your network that causes it. Please provide details of your network. |
|
As it finally happened again a few minutes ago (kern.log flooded, network completely dead, only system reboot works around this issue): do you want me to open a new issue with the correct chip or to give more detailed information in this issue tracker? E. g. there‘s no pattern, it happens randomly but usually after a longer System uptime, this time more than 11 days. |
|
Please start a new issue with all the details, including specifying the Pi/chip combo in the subject. Thanks. |
|
Done. #2928 |
|
Hi,
Fwiw, i've not gotten these the last year or so. When i got these (iirc) i was running self-compiled kernels and 4 systemd nspawn containers on my rpi2. "System pressure' might be a factor.
Anders
…On 10 April 2019 00:06:39 CEST, bcutter ***@***.***> wrote:
Done. #2928
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#2027 (comment)
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
|
On a recent install of rpi-4.9.y, 4.9.28, I get this after a period of constant tv streaming.
smsc95xx_eth0_kevent_0_may_have_been_dropped.txt
Didn't get it all, so I attach frech dmesg as well to get a view on the early parts.
4.9.28_dmesg.txt
The text was updated successfully, but these errors were encountered: