Kernel panic with high network(wifi) speeds + usb storage

[guisacouto]

My problem is basically the same there was some time ago when someone was doing high speed downloads and at the same time saving this to an external usb storage; this was fixed I know.. but I think it was only partly fixed.

I'm still having this problem with updated kernel and firmware (tried with the packages in the repos and also with rpi-update), because I use wifi instead of ethernet connection.

Playing movies through network streaming works just fine, but when I'm torrenting something at a decent speed I just get the kernel panic.

My guess is that there was something fixed for the smsc95xx ethernet chip, but not for every usb device that's compeeting for the unique usb bus that the raspi has.

Any help would be appreciated:)

best regards!

[pepedog]

Back in November, I must have spent 100 hours on this. It's the Synopsis On The Go driver (OTG) I believe at fault.
Nearly took hammer to Pi.
Get a Cubox, or if headless is ok a pogoplug V2

[guisacouto]

What do you mean? No solution?

[pepedog]

Well, it's beyond me. Can you do large downloads (not torrents) without problems?

[guisacouto]

Haven't tried it.. but did try with two clients (transmission and rtorrent).

Let me try download some linux distro with wget.

[guisacouto]

I had to put 6 wgets running at the same time to get some CPU load. Otherwise it would be very close to iddle.
After some time it panicked

edit:
Now I'm trying a new workaround (nut a solution but if it works, it would be nice). I've increased transmission cache from 4MB to 8MB. My guess is this should reduce the disk access to half. I also disabled encryption in transmission, because for what I read it's its botleneck.

edit2:
Still got the kernel panic... and the torrent who did it had just 4 peers.

[pepedog]

Have you seen these work arounds
https://github.com/raspberrypi/firmware/issues/9
$this->bbcode_second_pass_code('', 'vm.min_free_kbytes=32768 in /etc/sysctl.conf
while true ; do echo 3 > /proc/sys/vm/drop_caches ; sleep 1 ; done &')
Which start.elf do you have? I would switch to the arm224.
PS, this isn't just an arch issue, deb suffers too

[guisacouto]

Yes, I've done all the workarounds from the issue 9 in github, except the drop cache since for what I read didn't help (will try it anyway when I get home, can't ssh now since the raspi is off).

The maximum value I tried for min_free_kbytes was 21MB I think. I can try with 32 if you think can make the difference.
The start.elf I'm using is the 128, and I don't think it should be higher since the moment the rpi crashes htop in ssh tells me that I'm using around ~50MB.

For what I read in the rpi forums and in the github issue 9, is that this problem should be solved, and a lot of people is saying they don't have it anymore.. but it isn't for me so I'm a bit confused..

[pepedog]

I assume your USB storage is a hard drive, can you give me the wget url's and I will try.

[guisacouto]

Sure!

http://darkstar.ist.utl.pt/opensuse/12. ... D-i586.iso

I did 6 of those, otherwise the cpu would be really low.

Yes it's an western digital with power supply.

edit:
tried min_free_kbytes = 32768 and didn't worked. The drop caches hack doesn't help either.