So, after the yesterday experiences – Using more SDRAM to system and less in GPU – the kernel panic still happens.
Had seen a lot of people talking about heavy processes, and i think it must be connected, because system running idle hasn’t any problems.
So, as for today i’ve tryed a different approach: after reading some things about the interrupts in excess for such a machine – about 8000 getted with vmstat – and some saying it’s normal, and it’s related to the NIC driver from Broadcom which is using about 20% of resources, and while a new driver does’t appear, i’ve tryed a firmware update.
So, we’ve got a new kernel as i can see, and possible some more things. The upgrade firmware is quite easy to do, just follow the instructions where: https://github.com/Hexxeh/rpi-update
So at this point:
edurao@raspberrypi:~$ vmstat
procs ———–memory———- —swap– —–io—- -system– —-cpu—-
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 0 90272 40652 44264 0 0 0 0 402 142 17 3 79 1
edurao@raspberrypi:~$ uname -a
Linux raspberrypi 3.1.9+ #101 PREEMPT Mon Jun 4 17:19:44 BST 2012 armv6l GNU/Linux
Until now system looks stable, in this 3 hours… let’s see if it handles our stuff.
We’ve some heavy processes running using about 30% CPU, and since they’re threaded i think this could be the potential problem with the kernel panic interrupt fatality, but it’s kind of a wild guess…
top – 13:47:12 up 3:11, 1 user, load average: 0.28, 0.25, 0.27
Tasks: 63 total, 1 running, 62 sleeping, 0 stopped, 0 zombie
Cpu(s): 19.8%us, 3.3%sy, 0.0%ni, 74.6%id, 1.0%wa, 0.0%hi, 1.3%si, 0.0%st
Mem: 223048k total, 132824k used, 90224k free, 40692k buffers
Swap: 0k total, 0k used, 0k free, 44264k cached
Will update these random thoughts with more news when some stability is achieved
Eheh, é bom ver ‘tugas’ nestas andanças. Já recebi o meu rpi há perto de um mes e também tenho este problema..
Se so usar o xbmc e pouco mais (mesmo com streaming via wifi), não tenho qualquer problema.. já quando meto o transmission ou o rtorrent a fazer downloads, sao 15 mins e lá vem o kernel panic!
Já fiz de tudo.. o problema não está na falta de memoria já que o htop aquando do crash me indica como estava o sistema e a memoria esta à volta dos 50MB de utilização, portanto não é dai.
Pelo que já procurei acho que o defeito esta mesmo nos drivers usb do rpi, e acho que estes sao fechados, portanto não sei se tao cedo se terá solução para isto.
Boa sorte!
Olá Guilheme,
o meu também está neste momento com 51Mb de ram livres.
Não quero deitar foguetes antes da festa, mas parece-me que após este update ao firmware a coisa ficou estável.
Tenho tido isto a correr todo o dia sem nenhum crash. Parece-me bem pelo menos até agora 🙂
Deixa ver se assim continua.
Ou esse firmware é realmente muito recente, ou entao tenho serias duvidas 😛
Isto porque tenho actualizado sempre o maximo possivel, tanto através dos pacotes do archlinux, como também atraves do rpi-update.. e até agora nada, infelizmente não tive sucesso:\
Uma outra maneira facil de testar, é fazendo um mount através de sshfs, e transferir uns ficheiros do rpi para outra máquina. Tipicamente em pouco tempo lá aparece o kernel panic!
Não deixa de ser o gadget mais interessante com que já brinquei, tanto pelo facto de ser tão versátil, como por correr archlinux, e com a cereja no topo do bolo, o seu preço.
Vai deixando feedback:)
So stable now 🙂
pi@raspberrypi:~$ uptime
22:56:30 up 1 day, 12:20, 1 user, load average: 0.35, 0.41, 0.45
pi@raspberrypi:~$ vmstat
procs ———–memory———- —swap– —–io—- -system– —-cpu—-
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 0 11888 44348 109568 0 0 0 0 60 151 25 4 70 1
Creio que tenhamos problemas diferentes entao 😛
Pelos vistos o que te causava o kernel panic era ou o acaso, ou algo mais cpu intensive.
O meu problema, e de muitos utilizadores que se vê por ai espalhado na web, é antes referente à competição pelo único bus usb do rpi, que acaba por provocar o kernel panic.
Ainda bem que o update ao firmware resolveu o teu problema! Eu cá continuo com o meu 😛
Pois, mas a única coisa que mudámos foi mesmo o firmware.
O programinha continua a correr em background a usar os belos 30% de CPU, e seria isso.
Há imensas queixas de pessoas a usarem o RTorrent (acho que é isso) ou outro programa parecido de downloads.
No meu caso é mesmo um software que fizémos que é responsável por gerir um conjunto de pedidos e acessos http e numa base de dados.
Pelo menos parece resolvido ! Menos mal !