Raspberry Pi: Kernel Panic – Part II

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

6 thoughts on “Raspberry Pi: Kernel Panic – Part II

  1. 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!

  2. 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.

  3. 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:)

  4. 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

  5. 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 😛

  6. 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 !

Leave a Reply

Your email address will not be published. Required fields are marked *