raspivid crashes the Pi when storage is too slow

[caerandir]

Hi all,

I just wanted to report an issue using the CSI camera module and a "slow" SD card or a USB stick. I use a Class 6 SD card with 8 GB capacity and Raspian (apt-get update/upgraded today - i.e. May 24th; uname -a: Linux raspberrypi 3.6.11+ #456 PREEMPT Mon May 20 17:42:15 BST 2013 armv6l GNU/Linux). I have a Raspberry Pi Model B with 256 MB (the old version). When I do the following:

raspivid -o test.h264 -t 20000 -hf

I can crash the Pi by adding more load, e.g. by trying to connect to it via SSH. Screen goes blank and and Pi reboots. If I use a USB 3.0 USB stick as target for the file, the crash happens even without adding load, just after a few seconds. I checked the following things:

• Power - I attached even two power supplies adding up to 3 A of availabe power (although I admit not testing T1/T2)
• Overclocking - I removed any overclocking directives from config.txt
• Double-check that GPU mem is 128 MB (64 was also crashing Pi when capturing video)

Then I did the following:

raspivid --demo -t 20000 -hf

Then I can add as much load as I like, the Pi is stable, even using my overclocking settings.

What I can see also is, that when I really write the video-file, the CPU load is at 100%. When I do the demo, CPU is nearly idle.

So I guess it is something with IO, DMA, buffer overrun or whatever. The next thing I will try to get a class 10 or better SD card just to see what happens. I'll keep you posted.

Of course, any hints are welcome

Cheers

Caerandir

[jbeale]

My guess is same as yours, something to do with the speed of the memory. I guess if it is not fast enough, it should just drop the frame(s), but maybe it crashes instead.

On the other hand, extra network activity is also extra power draw. My calculations indicate the R-Pi Model B may be using 800 mA while recording .h264 video (260 mA above baseline when recording) and that is exceeding the nominal rating on the power input polyfuse (F3) of 700 mA. The difference between camera on and recording, and camera on but not recording is only 60 mA, but perhaps you are right at the threshold. If that is the problem, even unlimited power supply current capability will not help. Unless you connect +5V power directly via GPIO pins, which bypasses the fuse.

You might argue a polyfuse problem would affect everyone, but experience has shown there is a wide distribution of polyfuse resistance and there are some outlier boards with extra-high resistance (= voltage drop). So, it is possible you were just unlucky with your polyfuse.

[jamesh]

You could try dropping the bitrate on the encoder to see if it improves the situation. Defaults to 17000000, halving that would have the demand on the storage, so would be a good indicator if that is the problem.

[caerandir]

Hi all,

thanks for your replies. Unfortunately I seem to have a real problem. I did the following tests:

• Dropping the bitrate - that resulted in CPU usage dropping to near to nothing, but the problem persists
• Soldering a wire across polyfuse F3 - problem persists
• Measuring Voltage across TP1/TP2 - voltage is good but not very good with my "wall wart" power supplies
• Using a pretty good switching power supply rated 5V 3A and feed power in via GPIO pins - voltage at TP1/TP2 is very good now (never below 4.85 V) - problem persists
• Installed the latest wheezy image from the download page on a 16 GB class 10 Transcend SD card, running apt-get update/dist-upgrade/rpi-update and use good powersupply and run Pi without attached USB devices (only HDMI and network connected) - problem persists!!!

So, what I do is:

• run raspivid -o test.h264 -t 80000
• Use putty on a windows machine to connect

Really every time I do that, Pi crashes (blank screen, reboot). The same happens when I do other things that add load to the Pi. So e.g. if I remove the network cable (to rule out power consumption from the network hardware) and run:

raspivid -o test.h264 -t 10000000 -p 0,0,160,100

and then start scratch from the desktop icon *bang* crash. Or I run "cd /; find . | grep bla" - the command runs for a while, than *bang* crash. Or, I pick with the mouse the terminal window and move it around on the screen - after a few seconds - you guess it - crash.

If i do nothing, just let the Pi record the video, it runs smoothly for minutes. Although CPU usage is at 100%.

Anyone any idea???

Thanks, Caerandir

[jbeale]

hmm, seems like you are having a different experience than most. Are there any helpful error messages you can find in the various /var/log files?

[caerandir]

I am afraid the logfiles are of no help. I can see the crash indirectly by the clock juming back, but no helpful error message.

I tried around today with overvolting/undervolting, but no change in behaviour. Also not booting to desktop but staying at command line level did not help.

I come to the conclusion that my Pi is a lemon, even if a very subtle one. I think I will invest the money and get a second one (I cannot get myself to sending mine back - it is one of the "old" ones... ), having the double amount of RAM then as added value...

By the way, just out of curiosity if it IS related to the memory: has anyone reading this post also an "old" model B with 256 MB RAM and a CSI module? Could you try out if you experience the same effect?

Thanks again.

[poing]

I used an old 256MB model B board with a 8GB class 4 card over Putty; no problems. Had been using it for several hours until the ribbon cable gave in. I could get stills, video saved to the card and streaming to Windows without any problems.

[jamesh]

I did all the dev work on a 256MB model A....I don't even have a 512 one...

[caerandir]

OK, thanks for your replies. I think we can consider this thread closed - it must be a broken Pi. I will give it a try with ArchLinux just to be sure, but I do not have much hopes.

By the way, something I never mentioned: Besides my problem I like the camera and its software! The colors are very natural, the possibilities of the commands very good. Thank you for that!

[caerandir]

Hi folks,

the solution was so stupid I hardly dare to write it here. I was of the opinion that using raspi-config and its camera activation option will do all necessary steps to activate the camera, including to modify /boot/config.txt to use start_x.elf and fixup_x.elf. Which it did not. When I thought "oh, just let's copy these lines from the Raspbian SD to my new ArchLinux SD" I found them missing. Including them - everything seems to works like a charm (*hit head against wall*). It always comes as a surprise: If you do things correctly, it works... Sorry for bothering you!

By the way - what exactly *does* the raspi-config-option do?

Cheers

Caerandir

[jamesh]

This is odd. AFAIK, raspi-config swaps to start_x.elf and sets the gpu_mem to 218.

The camera would not have worked AT ALL, if it wasn't using a firmware with the camera driver in it - and that is start_x.elf.

[caerandir]

I am afraid you are right. It seems that I just experienced a lucky moment and wrote too fast about non-existing success... I could SSH while writing video, but only minutes later Pi crashed when trying to do my first stream. Since then: same effect . Just to be sure it is not some temperature related effect I'll try a little more with having the case open. *sigh*

[caerandir]

I give up now. It certainly has something to do with hardware timing and CPU workload. I fiddled around quite a lot with overclocking settings, and only strong overclocking allows the Pi to record video (crashing only if adding more load). Switching off overclocking even just recording the video crashes the Pi.

Just as I write this, the Pi crashed even on turbo mode writing the video without further load - so it seems the effect is getting worse, supporting the theory that the chip is somewhat broken . Perhaps it is a long-term effect of overclocking? I was running my Pi in the past with the highest clock settings that worked without overvolting. Perhaps that degrades the chip?

By the way, running raspi-config and selecting the option "Enable camera" adds a line to config.txt:

Code: Select all

start_x=1/0      (1 for enable, 0 for disable)

This seems to trigger boot with the "_x"-files. So thats at least explained.

[jamesh]

There should be no noticeable degradation from overclocking - it's like reducing chip life from 45 to 35 years. SO I wouldn't expect that to be a problem. I'd be a little suspicious about the SD card - did you say you had tried another one?

[caerandir]

Yes, I did, although only a few tests. The majority was done with the 8 GB class 6 card. OK, I'll try again the 16 GB class 10... I'll keep you posted.

[caerandir]

Things seem to be more complicated as I thought. When using the faster SD card things worked perfectly for a while. I could even get up a stable stream and then also add severe load, like installing a software package. Only after say 15 minutes things became unstable again. So I would say I have some temperature problem. This is also supported by the fact that I started my experiments after dinner, so the Pi had quite some time to cool down after my mistreating him over the afternoon. Using the slower SD card worsens the problem. When I use that one, I get crashes nearly immediately, while using the faster SD card still gives me 10-20 seconds of successful video stream before the crash. Wierd!

My last experiment for today was: Run the Pi with the fast SD card with no overclocking and with an awful bitrate (the CPU is at less then 10%). This runs for several minutes, no problems. I SSH into the pi (works), then run apt-get install audacity - *bang*.

My current opinion: I have one bad SD card AND a somewhat bad Pi.

Good night folks

Edit: Just started another test: A straem with default Bitrate - brings CPU up to about 95% load. Runs for 10 minutes, then crash. Chips feel pretty hot... but NOW good night

[caerandir]

Short update: I used a script to monitor CPU and GPU temperature - the crashes are not related to them... Still at a loss.

Does anybody know if it is possible to measure the temperature of the USB/network chip also?

Is there a documentation of all the commands of vcgencmd? I could only find a very few commands documented. There is one named "vctest_start" that - if issued - says "resource_failure_testing=started", but I have no idea what it does and how to get the test results. The best documentation I found is this:

https://github.com/nezticle/RaspberryPi ... Core-Tools

I'll try to dig into that the next days, but any help is appreciated.

I will most likely get a new Pi tomorrow - I will use the same SD card on it. I can hardly wait to see the results.

[dakleine]

Hi!

I have the same problem. After recording a 5 sec. video, the ssh session disconnects. The led of the cam keeps glowing. I cannot reconnect to the pi with the same remote ip but i am able to login in local with a usb keyboard to reboot the pi.

Btw i save the photos over the lan on a mounted nfs share.

dakleine

[caerandir]

Hi all,

for me it is now clear: Mi Pi is somewhat faulty. An hour ago my new Pi arrived and I am streaming since then with default bandwidth. Same SD-card, same OS installation, same configuration, same powersupply, same everything, "just" a new Pi. The temperature of the chip is nearly the same as with the old Pi.

I'm most curious now to see if other problems I had with USB on my old Pi will vanish as magically...

Does anyone think it is feasible to find out what is wrong with the "old" Pi? Tipps what I should check?

Thanks, Caerandir.

[caerandir]

The problem is solved! After all, I was not alone with the problem - I stumbled across this post: http://www.raspberrypi.org/phpBB3/viewt ... 28&t=44904. The solution is to add

Code: Select all

current_limit_override=0x5A000020

to config.txt (potentially voiding warrenty if used together with overclocking and overvolting). Obviously some Pi models have a problem with the current that is consumed by the GPU when CSI module is running.

[derkmdt]

Fixed the problem off crashing, by using another Pi... Fixes above didn't do the trick for me. Don't know what the reason is it didn't work with video for me.