Is this a SD-Card issue?

naicheben · Tue Jun 05, 2012 8:09 pm

I'm seeing these in dmesg, after network begins to stutter (-> mpd stutters in playback)

Mem-info:
Normal per-cpu:
CPU    0: hi:   42, btch:   7 usd:  41
active_anon:4151 inactive_anon:17 isolated_anon:0
 active_file:11729 inactive_file:11956 isolated_file:8
 unevictable:0 dirty:3 writeback:0 unstable:0
 free:653 slab_reclaimable:528 slab_unreclaimable:1181
 mapped:724 shmem:44 pagetables:150 bounce:0
Normal free:2612kB min:1440kB low:1800kB high:2160kB active_anon:16604kB inactive_anon:68kB active_file:46916kB inactive_file:47824kB unevictable:0kB isolated(anon):0kB isolated(file):32kB present:130048kB mlocked:0kB dirty:12kB writeback:0kB mapped:2896kB shmem:176kB slab_reclaimable:2112kB slab_unreclaimable:4724kB kernel_stack:520kB pagetables:600kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:10 all_unreclaimable? no
lowmem_reserve[]: 0 0
Normal: 471*4kB 55*8kB 12*16kB 3*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 2612kB
23734 total pagecache pages
0 pages in swap cache
Swap cache stats: add 0, delete 0, find 0/0
Free swap  = 0kB
Total swap = 0kB
32768 pages of RAM
819 free pages
1869 reserved pages
1709 slab pages
4291 pages shared
0 pages swap cached
smsc95xx 1-1.1:1.0: eth0: kevent 2 may have been dropped
smsc95xx 1-1.1:1.0: eth0: kevent 2 may have been dropped
kworker/0:1: page allocation failure: order:3, mode:0x20
Backtrace: 
Function entered at [<c0011870>] from [<c0474694>]
 r6:c78be000 r5:00000003 r4:00000020 r3:00000002
Function entered at [<c047467c>] from [<c007248c>]
Function entered at [<c00723c0>] from [<c0074828>]
 r3:00000000 r2:00000000
 r7:00000003 r6:c78be000 r5:00000000 r4:00000000
Function entered at [<c0074330>] from [<c047562c>]
Function entered at [<c047533c>] from [<c009a5e0>]
Function entered at [<c009a504>] from [<c03a5c74>]
 r7:00004a20 r6:c780bce0 r5:00000020 r4:c68aa440
Function entered at [<c03a5c24>] from [<c032e938>]
Function entered at [<c032e90c>] from [<c032f670>]
 r8:c78be000 r7:00000002 r6:c79ec360 r5:00000004 r4:00000006
r3:00000000
Function entered at [<c032f45c>] from [<c0027cac>]
 r7:00000000 r6:c0597ee0 r5:00000000 r4:c055b9c4
Function entered at [<c0027c04>] from [<c00282a8>]
 r7:c0597f04 r6:c0597f20 r5:00000018 r4:00000001
Function entered at [<c00281fc>] from [<c002876c>]
Function entered at [<c00286d8>] from [<c000eb20>]
 r4:c0567dac r3:c0060358
Function entered at [<c000eae4>] from [<c0008190>]
 r6:f200b200 r5:20000113 r4:c0011618 r3:c0011658
Function entered at [<c0008180>] from [<c000de34>]
Exception stack(0xc78bfae8 to 0xc78bfb30)
fae0:                   00000000 c78bfb88 c001b788 c78bfb68 c78bfb68 c78bfb60
fb00: c0010204 c066f120 c78bfbd8 c0856178 00000001 c78bfb3c c78bfb40 c78bfb30
fb20: c0011658 c0011618 20000113 ffffffff
Function entered at [<c00115bc>] from [<c0011658>]
Function entered at [<c0011624>] from [<c0010270>]
 r6:c78bfc68 r5:00000001 r4:c78be000 r3:c0010234
Function entered at [<c0010234>] from [<c001b788>]
Function entered at [<c001b724>] from [<c007a3a0>]
 r5:00000000 r4:c066f120
Function entered at [<c007a2a8>] from [<c007bb64>]
 r5:c78bfd88 r4:c066f134
Function entered at [<c007b744>] from [<c007c3f4>]
Function entered at [<c007c2a8>] from [<c007c948>]
Function entered at [<c007c560>] from [<c007d3f4>]
Function entered at [<c007d378>] from [<c007d88c>]
Function entered at [<c007d814>] from [<c00746dc>]
 r6:c05770d8 r5:00000000 r4:00000000
Function entered at [<c0074330>] from [<c047562c>]
Function entered at [<c047533c>] from [<c009a5e0>]
Function entered at [<c009a504>] from [<c03a5c74>]
 r7:00004a20 r6:c780bce0 r5:000000d0 r4:c08ae6e0
Function entered at [<c03a5c24>] from [<c032e938>]
Function entered at [<c032e90c>] from [<c032ed20>]
 r8:c032eb08 r7:00000000 r6:c780f400 r5:c79ec360 r4:c79ec458
r3:a0000113
Function entered at [<c032eb08>] from [<c0038f54>]
 r6:c780f400 r5:c78ba7a0 r4:c79ec458
Function entered at [<c0038e20>] from [<c0039be0>]
Function entered at [<c0039a68>] from [<c003e1e4>]
Function entered at [<c003e158>] from [<c0025d84>]
 r6:c0025d84 r5:c003e158 r4:c782deec
Mem-info:
Normal per-cpu:
CPU    0: hi:   42, btch:   7 usd:  41
active_anon:4151 inactive_anon:17 isolated_anon:0
 active_file:11729 inactive_file:11956 isolated_file:8
 unevictable:0 dirty:3 writeback:0 unstable:0
 free:653 slab_reclaimable:528 slab_unreclaimable:1181
 mapped:724 shmem:44 pagetables:150 bounce:0
Normal free:2612kB min:1440kB low:1800kB high:2160kB active_anon:16604kB inactive_anon:68kB active_file:46916kB inactive_file:47824kB unevictable:0kB isolated(anon):0kB isolated(file):32kB present:130048kB mlocked:0kB dirty:12kB writeback:0kB mapped:2896kB shmem:176kB slab_reclaimable:2112kB slab_unreclaimable:4724kB kernel_stack:520kB pagetables:600kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:10 all_unreclaimable? no
lowmem_reserve[]: 0 0
Normal: 471*4kB 55*8kB 12*16kB 3*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 2612kB
23734 total pagecache pages
0 pages in swap cache
Swap cache stats: add 0, delete 0, find 0/0
Free swap  = 0kB
Total swap = 0kB
32768 pages of RAM
819 free pages
1869 reserved pages
1709 slab pages
4291 pages shared
0 pages swap cached
smsc95xx 1-1.1:1.0: eth0: kevent 2 may have been dropped
kworker/0:1: page allocation failure: order:3, mode:0x20
Backtrace: 
Function entered at [<c0011870>] from [<c0474694>]
 r6:c78be000 r5:00000003 r4:00000020 r3:00000002
Function entered at [<c047467c>] from [<c007248c>]
Function entered at [<c00723c0>] from [<c0074828>]
 r3:00000000 r2:00000000
 r7:00000003 r6:c78be000 r5:00000000 r4:00000000
Function entered at [<c0074330>] from [<c047562c>]
Function entered at [<c047533c>] from [<c009a5e0>]
Function entered at [<c009a504>] from [<c03a5c74>]
 r7:00004a20 r6:c780bce0 r5:00000020 r4:c68aa440
Function entered at [<c03a5c24>] from [<c032e938>]
Function entered at [<c032e90c>] from [<c032f670>]
 r8:c78be000 r7:00000002 r6:c79ec360 r5:00000004 r4:00000005
r3:00000000
Function entered at [<c032f45c>] from [<c0027cac>]
 r7:00000000 r6:c0597ee0 r5:00000000 r4:c055b9c4
Function entered at [<c0027c04>] from [<c00282a8>]
 r7:c0597f04 r6:c0597f20 r5:00000018 r4:00000001
Function entered at [<c00281fc>] from [<c002876c>]
Function entered at [<c00286d8>] from [<c000eb20>]
 r4:c0567dac r3:c0060358
Function entered at [<c000eae4>] from [<c0008190>]
 r6:f200b200 r5:20000113 r4:c0011618 r3:c0011658
Function entered at [<c0008180>] from [<c000de34>]
Exception stack(0xc78bfae8 to 0xc78bfb30)
fae0:                   00000000 c78bfb88 c001b788 c78bfb68 c78bfb68 c78bfb60
fb00: c0010204 c066f120 c78bfbd8 c0856178 00000001 c78bfb3c c78bfb40 c78bfb30
fb20: c0011658 c0011618 20000113 ffffffff
Function entered at [<c00115bc>] from [<c0011658>]
Function entered at [<c0011624>] from [<c0010270>]
 r6:c78bfc68 r5:00000001 r4:c78be000 r3:c0010234
Function entered at [<c0010234>] from [<c001b788>]
Function entered at [<c001b724>] from [<c007a3a0>]
 r5:00000000 r4:c066f120
Function entered at [<c007a2a8>] from [<c007bb64>]
 r5:c78bfd88 r4:c066f134
Function entered at [<c007b744>] from [<c007c3f4>]
Function entered at [<c007c2a8>] from [<c007c948>]
Function entered at [<c007c560>] from [<c007d3f4>]
Function entered at [<c007d378>] from [<c007d88c>]
Function entered at [<c007d814>] from [<c00746dc>]
 r6:c05770d8 r5:00000000 r4:00000000
Function entered at [<c0074330>] from [<c047562c>]
Function entered at [<c047533c>] from [<c009a5e0>]
Function entered at [<c009a504>] from [<c03a5c74>]
 r7:00004a20 r6:c780bce0 r5:000000d0 r4:c08ae6e0
Function entered at [<c03a5c24>] from [<c032e938>]
Function entered at [<c032e90c>] from [<c032ed20>]
 r8:c032eb08 r7:00000000 r6:c780f400 r5:c79ec360 r4:c79ec458
r3:a0000113
Function entered at [<c032eb08>] from [<c0038f54>]
 r6:c780f400 r5:c78ba7a0 r4:c79ec458
Function entered at [<c0038e20>] from [<c0039be0>]
Function entered at [<c0039a68>] from [<c003e1e4>]
Function entered at [<c003e158>] from [<c0025d84>]
 r6:c0025d84 r5:c003e158 r4:c782deec
Mem-info:
Normal per-cpu:
CPU    0: hi:   42, btch:   7 usd:  41
active_anon:4151 inactive_anon:17 isolated_anon:0
 active_file:11729 inactive_file:11956 isolated_file:8
 unevictable:0 dirty:3 writeback:0 unstable:0
 free:653 slab_reclaimable:528 slab_unreclaimable:1181
 mapped:724 shmem:44 pagetables:150 bounce:0
Normal free:2612kB min:1440kB low:1800kB high:2160kB active_anon:16604kB inactive_anon:68kB active_file:46916kB inactive_file:47824kB unevictable:0kB isolated(anon):0kB isolated(file):32kB present:130048kB mlocked:0kB dirty:12kB writeback:0kB mapped:2896kB shmem:176kB slab_reclaimable:2112kB slab_unreclaimable:4724kB kernel_stack:520kB pagetables:600kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:10 all_unreclaimable? no
lowmem_reserve[]: 0 0
Normal: 471*4kB 55*8kB 12*16kB 3*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 2612kB
23734 total pagecache pages
0 pages in swap cache
Swap cache stats: add 0, delete 0, find 0/0
Free swap  = 0kB
Total swap = 0kB
32768 pages of RAM
819 free pages
1869 reserved pages
1709 slab pages
4291 pages shared
0 pages swap cached
smsc95xx 1-1.1:1.0: eth0: kevent 2 may have been dropped

The last line seems to be repeated a million times ...

Now I wonder if it is related to SD-Card, sound or network.

neilpercy · Sun Jun 10, 2012 3:12 pm

Code: Select all

smsc95xx 1-1.1:1.0: eth0: kevent 2 may have been dropped
smsc95xx 1-1.1:1.0: eth0: kevent 2 may have been dropped
smsc95xx 1-1.1:1.0: eth0: kevent 2 may have been dropped
smsc95xx 1-1.1:1.0: eth0: kevent 2 may have been dropped
......

I'm also seeing this message.

Happens when I'm trying to install packages for Bluetooth, and a couple of other times ????

AH! - ANSWER here

neil

pepedog · Sun Jun 10, 2012 3:56 pm

I came up with this (possible) solution last November.
It's being discussed here
http://archlinuxarm.org/forum/viewtopic ... =10#p17654
I was still getting it under heavy load, now stopped, but still happening for others

brightspirit · Wed Jun 13, 2012 5:01 pm

This happened to me when I got a powered usb hub. I found that the plug was causing feedback through pin 1 (+5V). All I did was cover that pin up with pvc tape and it started working clear as a bell

gregjo · Wed Jun 13, 2012 6:14 pm

brightspirit wrote:This happened to me when I got a powered usb hub. I found that the plug was causing feedback through pin 1 (+5V). All I did was cover that pin up with pvc tape and it started working clear as a bell

I'm all game to give this a try. I'm seeing the same issue. Where is pin 1? Is it P1 labeled in the upper left of this image?

(Use this link if you need to see the image zoomed.)
http://elinux.org/images/1/15/RPi_beta_xray.jpg

pepedog, I seem to be getting much more reliable network performance when I add "smsc95xx.turbo_mode=N" to my /boot/commandline.txt file. (I'm using one of the Fedora 17 nightly builds)

Wed Jun 13, 2012 6:30 pm

Its not the connector of the RPI that you need to tape-off, its the connector of the cable, the plug (not the USB connector of the PI) where you can cover pin 1, follow this URL to see a picture of the plug explaining which pin is pin-1 (VBUS or +5V):

http://en.wikipedia.org/wiki/File:USB.svg

EDIT: actually it seems this picture caused some confusion, as it may have been interpreted as the view inside the PI's USB connector, here is a better picture:

Notes;
1) you have to tape off the VBUS (+5V) pin.
2) The picture shown is actually the connector (plug) for the new standard USB-3, (not USB-2) but just ignore the 5 pins which are labeled in red, which are for the new high speed USB-3 connections.
3) In this picture the D- and D+ pins are interchanged, D- is next to VBUS not GND, not that this matters here, but I double checked with Wikipedia, it seems a common error.
Its hard to find a suitable picture for here that shows both the pinning and that its the plug, not the receptacle!

pepedog · Wed Jun 13, 2012 6:36 pm

pepedog, I seem to be getting much more reliable network performance when I add "smsc95xx.turbo_mode=N" to my /boot/commandline.txt file. (I'm using one of the Fedora 17 nightly builds)

I thought so too. New rootfs is built with it.

brightspirit · Thu Jun 14, 2012 9:20 pm

I just taped over a +5V pin on the USB plug that I put in the RPi with standard PVC tape.

: USB_A_pinout.jpg (8.77 KiB) Viewed 23012 times

elatllat · Thu Aug 02, 2012 3:15 pm

If a few more people could confirm this it would help.

http://elinux.org/RPi_Bugs

AndrewS · Fri Aug 03, 2012 12:53 am

elatllat wrote:If a few more people could confirm this it would help.

http://elinux.org/RPi_Bugs

I've not seen these error messages myself, but there's definitely a problem with lots of 'non standard' powered USB hubs supplying power back to the Pi, which they shouldn't be doing (can lead to excessive current flow). Most people choose to just cut the +5V wire inside the USB cable / inside the hub.

elatllat · Sat Aug 04, 2012 5:50 am

brightspirit wrote:I just taped over a +5V pin on the USB plug that I put in the RPi with standard PVC tape.

USB_A_pinout.jpg

USB failed to work completely when I tried this.
But the USB did work when I taped over the left pin.
(makes sense the pins are reversed on the other end of the plug)

elatllat · Tue Aug 07, 2012 10:09 pm

I cut the power lines in the USB cable and I'm still getting thousands (1748) of these:

Code: Select all

[ 3016.652712] smsc95xx 1-1.1:1.0: eth0: kevent 2 may have been dropped
[ 3016.652739] smsc95xx 1-1.1:1.0: eth0: kevent 2 may have been dropped
[ 3016.652779] smsc95xx 1-1.1:1.0: eth0: kevent 2 may have been dropped

also

Code: Select all

grep vm.min /etc/sysctl.conf
vm.min_free_kbytes = 8192
free
             total       used       free     shared    buffers     cached
Mem:        220644     200484      20160          0       3592     148184
-/+ buffers/cache:      48708     171936
Swap:       102396      10300      92096

dht in rtorrent "...may cause genuine non-DHT connections to be dropped..."
sounds bad out of context but read this:
http://libtorrent.rakshasa.no/wiki/RTorrentUsingDHT

Code: Select all

ifconfig eth0
eth0      Link encap:Ethernet  HWaddr b8:27:eb:9e:87:2a  
          inet addr:192.168.0.110  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4438435 errors:0 dropped:97 overruns:0 frame:0
          TX packets:3562919 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:3690746889 (3.4 GiB)  TX bytes:2383531943 (2.2 GiB)

bfromcolo · Sun Aug 12, 2012 6:35 pm

I sacrificed a USB cable and tried cutting the +5 line as suggested, but this has resulted in an inability to communicate with any devices attached to the hub. Is there any other work around for this, perhaps a resistor to limit current flow between the devices but leave it connected?

It is apparent this has been a known problems for months, it would have been nice to know this issue existed before I ordered the card.

elatllat · Sun Aug 12, 2012 6:45 pm

bfromcolo wrote:I sacrificed a USB cable and tried cutting the +5 line as suggested, but this has resulted in an inability to communicate with any devices attached to the hub. Is there any other work around for this, perhaps a resistor to limit current flow between the devices but leave it connected?

It is apparent this has been a known problems for months, it would have been nice to know this issue existed before I ordered the card.

a) you cut the wrong wire
b) cutting the right wire won't help anyway
c) some related problems can be caused by an under powered power supply or cord but not all.
c) it's a driver problem that is being worked on.

When it's fixed you will see it here:
https://github.com/raspberrypi/firmware/commits/master

bfromcolo · Sun Aug 12, 2012 7:16 pm

elatllat wrote:
a) you cut the wrong wire
b) cutting the right wire won't help anyway
c) some related problems can be caused by an under powered power supply or cord but not all.
c) it's a driver problem that is being worked on.

When it's fixed you will see it here:
https://github.com/raspberrypi/firmware/commits/master

LOL, I cut the right wire +5 wire, verified with my multimeter and everything. Maybe my hub senses that being connected. Anyway I hope your right about its being a firmware issue, I would prefer to not have to buy a different hub.

elatllat · Sun Aug 12, 2012 7:44 pm

the reason I said you might have cut the wrong wire is because I did a similar thing;
taped one, nothing worked, taped the other side and things worked.

dmesg output is always good

elatllat · Sun Aug 12, 2012 9:15 pm

setting

Code: Select all

vm.min_free_kbytes = 16384

in /etc/sysctl.conf

seems to have removed these errors:

Code: Select all

eth0: kevent 2 may have been dropped

elatllat · Sun Aug 12, 2012 9:46 pm

or not

... maybe I'll try a bigger number.

elatllat · Sun Aug 12, 2012 10:55 pm

added "smsc95xx.turbo_mode=N" to /boot/cmdline.txt , so far so good

jbeale · Mon Aug 13, 2012 4:21 am

Not that it matters for most people, but the illustration of the USB port pinout several posts back has an error: D+ and D- are reversed. D- is always the pin next to +5 V.

Code: Select all

 The USB Pinout:
Pin 	Name 	Cable color    Description
1 	VCC           Red         +5 VDC
2 	D- 	        White 	   Data -
3 	D+ 	        Green 	   Data +
4 	GND 	       Black       Ground

elatllat · Mon Aug 13, 2012 5:45 pm

adding "smsc95xx.turbo_mode=N" works!
no more crashing!

pepedog · Mon Aug 13, 2012 8:39 pm

elatllat wrote:adding "smsc95xx.turbo_mode=N" works!
no more crashing!

I made a post last October on this
http://www.raspberrypi.org/phpBB3/viewt ... urbo#p8249

bartender · Fri Jan 25, 2013 3:45 pm

I still experience infinite kernel panics when copying big files over NFS to SD card. And I have that option in cmdline.txt already set.
Have tried with:
1. 2 different boards (256M and 512M)
2. 2 SD cards (Transcend 16G class 4 and 32G class 10)
3. With and without hub plugged in (non-powered)
4. 2 different power suppiles.
5. 2 kernels (Arch's stock and the one supplied by rpi-update)

And still no errors in Raspbian, why?

upd: looks like this not only happens on heavy network load, but on heavy SD read/write too.

sdjf · Fri Jan 25, 2013 4:01 pm

There seems to have been a limit on amount of data being transferred over scp, I do not know if this is related, but several weeks ago, attempting to scp an alarm image of about 160MB to the Pi, scp stopped, saying a limit had been reached. Sorry, I do not think I saved output, so cannot be positive which side it was on, Pi or the other end. And I think it was with scp to a Sept version of alarm.

drirr · Fri Jan 25, 2013 4:24 pm

bartender wrote:I still experience infinite kernel panics when copying big files over NFS to SD card. And I have that option in cmdline.txt already set.
5. 2 kernels (Arch's stock and the one supplied by rpi-update)

Have you tried the arch 3.6 kernel (the -next packages)? Otherwise I'd suggest to try them.

sdjf wrote:There seems to have been a limit on amount of data being transferred over scp, I do not know if this is related, but several weeks ago, attempting to scp an alarm image of about 160MB to the Pi, scp stopped, saying a limit had been reached. Sorry, I do not think I saved output, so cannot be positive which side it was on, Pi or the other end. And I think it was with scp to a Sept version of alarm.

This is a bit off topic, but it sounds like an error on the receiving end. I've transfered hundreds of megabyte using scp to my rpi. Though as the CPU is weak I've switched to vsftpd with tls, scp gives me ~1.8MB/s whereas FTP gives me ~8MB/s. So if you're going to transfer big amounts of data to the rpi, don't use scp unless you really have too.

Is this a SD-Card issue?

Is this a SD-Card issue?

Re: Is this a SD-Card issue?

Re: Is this a SD-Card issue?

Re: Is this a SD-Card issue?

Re: Is this a SD-Card issue?

Re: Is this a SD-Card issue?

Re: Is this a SD-Card issue?

Re: Is this a SD-Card issue?

Re: Is this a SD-Card issue?

Re: Is this a SD-Card issue?

Re: Is this a SD-Card issue?

Re: Is this a SD-Card issue?

Re: Is this a SD-Card issue?

Re: Is this a SD-Card issue?

Re: Is this a SD-Card issue?

Re: Is this a SD-Card issue?

Re: Is this a SD-Card issue?

Re: Is this a SD-Card issue?

Re: Is this a SD-Card issue?

Re: Is this a SD-Card issue?

Re: Is this a SD-Card issue?

Re: Is this a SD-Card issue?

Re: Is this a SD-Card issue?

Re: Is this a SD-Card issue?

Re: Is this a SD-Card issue?