Linux: bcm2835_v4l2 no kernel RPi1 oops

Você pode identificar a atualização exata que causou isso. Ver:
https://github.com/Hexxeh/rpi-firmware/commits/master

Se você clicar em cada commit, o final da url contém um git hash. Corre
sudo rpi-update <hash>
para voltar a essa versão. Relate a primeira versão com este erro.

Em um palpite https://github.com/Hexxeh/rpi-firmware/commit/6d158adcc0cfa03afa17665715706e6e5f0750d2 será a primeira versão com o problema - essa foi a primeira a incluir a consulta da GPU para resolução máxima do sensor, feita em bm2835_mmal_init .
9dc0b88f1d3b5e9400e4adaadd13a4ef5e7348fa é o anterior a isso.

Não consigo ver nada de errado com o manuseio, então não posso dar nenhum conselho. Eu testei isso bastante em Pi2 e CM3, e não há diferença significativa nessa área para Pi1. Visto que você está no 4.4.8, suponho que você tenha usado rpi-update e atualizado o firmware, bem como o kernel. Houve uma alteração de firmware associada a essa solicitação também.

Posso confirmar que o modprobing bcm2835-v4l2 trava o kernel aqui.

Especificações:

Hardware        : BCM2708
Revision        : 000e

Executando o Arch Linux ARM:

linux-raspberrypi 4.4.8-2
raspberrypi-firmware-tools 20160503-1
raspberrypi-firmware-bootloader-x 20160503-1
raspberrypi-firmware-bootloader 20160503-1
linux-firmware 20160315.deb1d83-1

Não vendo uma falha do kernel aqui. O que:

vcgencmd version
uname -a

relatório?

/opt/vc/bin/vcgencmd version
May  3 2016 17:47:44 
Copyright (c) 2012 Broadcom
version b870a5bbf6c662327916ee582c22309c9f997b3d (clean) (release)

uname -a
Linux alarmpi 4.4.8-2-ARCH #1 Tue Apr 26 19:13:10 MDT 2016 armv6l GNU/Linux

Tentei com o kernel 4.4.9 fresco:

[  111.269707] media: Linux media interface: v0.10
[  111.370081] Linux video capture interface: v2.00
[  111.490692] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[  111.499124] pgd = d30d0000
[  111.501988] [00000000] *pgd=11050831, *pte=00000000, *ppte=00000000
[  111.508592] Internal error: Oops: 17 [#1] ARM
[  111.513040] Modules linked in: bcm2835_v4l2(+) videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core v4l2_common videodev media cfg80211 i2c_bcm2708 spi_bcm2835 bcm2835_gpiomem bcm2835_wdt uio_p
drv_genirq uio sch_fq_codel bcm2835_rng rng_core ip_tables x_tables ipv6
[  111.538374] CPU: 0 PID: 655 Comm: modprobe Not tainted 4.4.9-1-ARCH #1
[  111.545014] Hardware name: BCM2708
[  111.548486] task: d6b0dda0 ti: d3330000 task.ti: d3330000
[  111.554070] PC is at bm2835_mmal_init+0x78/0x738 [bcm2835_v4l2]
[  111.560098] LR is at 0x0
[  111.562689] pc : [<bf1c3078>]    lr : [<00000000>]    psr: a0000113
               sp : d3331d90  ip : 00000000  fp : 2cded15c
[  111.574345] r10: 00000001  r9 : bf1bf394  r8 : 00000000
[  111.579664] r7 : bf1c3000  r6 : 00000000  r5 : 00000000  r4 : d5479800
[  111.586299] r3 : bf1be644  r2 : 00000000  r1 : 00000000  r0 : d5479800
[  111.592939] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[  111.600195] Control: 00c5387d  Table: 130d0008  DAC: 00000055
[  111.608475] Process modprobe (pid: 655, stack limit = 0xd3330188)
[  111.617228] Stack: (0xd3331d90 to 0xd3332000)
[  111.624239] 1d80:                                     00000002 c04bb040 ff0a0005 00000000
[  111.637730] 1da0: 00000020 00000001 d3334000 ffffffff 00000a20 00000798 00000000 00000000
[  111.651265] 1dc0: d55e4640 00000000 d3212ec0 00000001 2cded15c c04bdc84 d541e018 d3331e08
[  111.664982] 1de0: d6a19480 bf1bf620 00000001 c0a94f30 c0a94f30 d55e4640 bf1c3000 00000000
[  111.678910] 1e00: d3212ec0 00000001 2cded15c c00094b8 f348c558 00000019 00000001 d3330000
[  111.693103] 1e20: d3330000 d7001e60 d3212ec8 024000c0 c00cf9b8 0000000c d3331e4c c0794be4
[  111.707440] 1e40: 024000c0 d7001e60 d3331e54 c0794c30 2cded15c c0114618 2cded15c c00d6fd8
[  111.721988] 1e60: bf1bf620 00000001 d55e45e0 bf1bf620 bf1bf668 00000001 2cded15c c00cf9f4
[  111.736774] 1e80: d3331f44 00000001 d3331f44 00000001 d3212ec8 c007c2c0 bf1bf62c 00007fff
[  111.751777] 1ea0: bf1bf620 c0079ae4 c0079560 bf1bf718 00000000 d90d9304 bf1bf7d4 bf1bf62c
[  111.767050] 1ec0: 00000000 c079e4d0 00400000 d32123c0 0192b280 c0105160 00400000 00000000
[  111.782634] 1ee0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[  111.798354] 1f00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0000e354
[  111.814304] 1f20: 00000000 b4c1335c d90d9354 0002bce8 d3330000 00000000 0192b280 c007c8ac
[  111.830396] 1f40: 00001a04 d90cb000 0000e354 d90d8c9c d90d8ad8 d90d5f24 00007814 00008944
[  111.846489] 1f60: 00000000 00000000 00000000 000031dc 00000029 0000002a 0000001f 00000023
[  111.862574] 1f80: 00000018 00000000 00005a04 0192b060 b4c05008 00040000 00000080 c000f0a4
[  111.878688] 1fa0: d3330000 c000ef00 0192b060 b4c05008 b4c05008 0000e354 0002bce8 c7037e00
[  111.894805] 1fc0: 0192b060 b4c05008 00040000 00000080 0002bce8 00000000 00000000 0192b280
[  111.910935] 1fe0: 0003e164 bed28930 00020bb4 b6e34670 60000010 b4c05008 8080827f 7f808283
[  111.927210] [<bf1c3078>] (bm2835_mmal_init [bcm2835_v4l2]) from [<c00094b8>] (do_one_initcall+0x80/0x1dc)
[  111.944797] [<c00094b8>] (do_one_initcall) from [<c00cf9f4>] (do_init_module+0x5c/0x1c0)
[  111.960780] [<c00cf9f4>] (do_init_module) from [<c007c2c0>] (load_module+0x1ad8/0x1fa0)
[  111.976609] [<c007c2c0>] (load_module) from [<c007c8ac>] (SyS_init_module+0x124/0x140)
[  111.992332] [<c007c8ac>] (SyS_init_module) from [<c000ef00>] (ret_fast_syscall+0x0/0x34)
[  112.008146] Code: 0a000188 e59d200c e59f3634 e082e186 (e792c186)
[  112.018482] ---[ end trace 8fb7666a31e04815 ]---
[  113.949638] cfg80211: Verifying active interfaces after reg change
[root<strong i="6">@campi</strong> kad]# /opt/vc/bin/vcgencmd version
May  6 2016 13:57:24
Copyright (c) 2012 Broadcom
version 0cc642d53eab041e67c8c373d989fef5847448f8 (clean) (release)
[root<strong i="7">@campi</strong> kad]# uname -a
Linux campi 4.4.9-1-ARCH #1 Fri May 6 12:52:21 MDT 2016 armv6l GNU/Linux
[root<strong i="8">@campi</strong> kad]#

a compilação do kernel corresponde ao commit 68bead249ca6ad97fc39a0780471f4b65402afc1
referência: https://github.com/archlinuxarm/PKGBUILDs/blob/master/core/linux-raspberrypi/PKGBUILD

@kad você estava executando raspbian ou arch?

Local onde posso reproduzir esse travamento está executando o Arch

Não acredito que isso afete o raspbian. O Arch constrói um kernel personalizado, então o problema seria melhor relatado lá.

Problema relatado em ambos os lugares...
O Arch usa o kernel deste repositório e, de acordo com o PKGBUILD, não vejo como os componentes do espaço do usuário ou patches adicionais para aufs4 e BFQ poderiam interferir no V4L, portanto, relatado no upstream, ou seja, neste repositório.

O Arch constrói um kernel personalizado com base nas fontes aqui, mas com diferentes patches e opções de configuração, então não podemos oferecer suporte para problemas que afetam o Arch e não o raspbian.

Reproduza o problema com o raspbian e podemos ajudar mais.

Você pode apontar para qualquer imagem raspbian (teste) que tenha kernel 4.4.8+? lugares onde tenho raspbian, todos rodando 4.1.19.

Basta usar o raspbian mais recente e executar o rpi-update.
Ou espere cerca de uma semana para uma imagem raspbian atualizada.

De fato, com o kernel binário de https://github.com/Hexxeh/rpi-firmware , não consigo reproduzir a mesma falha.
Não há diferença de código entre o kernel do Arch e o rpi-firmware nesse espaço, mas as configurações do kernel são diferentes.

CC: @kmihelich

Ao mesmo tempo, olhando brevemente para bcm2835-camera.c, posso ver alguns lugares onde os ponteiros seguiram sem verificação de que eles não são NULL :(

Isso para mim se parece muito com um relatório de bug para um kernel, que é para que serve este repositório. Não para uma distribuição do Debian reconstruída para ARMv6.

Um bug no seu código está obviamente presente, dados os logs acima. Se um bug em seu kernel surgiu devido a uma configuração diferente, você deve investigar por que seu código está falhando. Se você não estiver verificando seus ponteiros adequadamente e isso de alguma forma não for um problema em sua configuração específica e ambiente de compilação, isso _não_ significa que não é um problema com seu código. Tentar varrer isso para debaixo do tapete dizendo "você não está usando nossa configuração, portanto não é problema nosso" é uma atitude pouco profissional a ser adotada no desenvolvimento do kernel.

Bugs ou a falta de tratamento de erros são algumas das fontes mais comuns de problemas. Embora investigaremos e corrigiremos quaisquer erros que encontrarmos, isso pode não ajudar seus usuários que ainda enfrentam uma mensagem de erro, portanto, verifique se sua casa está em ordem.

Estamos falando de uma mensagem de erro de desreferência de ponteiro nulo _do kernel_. Esta mensagem não vem do código do espaço do usuário.

Que, se estiver em caminho de erro, é provocado por um erro (daí o nome). Como o Raspbian não exibe a falha, o erro provavelmente é causado por uma configuração de kernel diferente ou atividade de espaço do usuário diferente, que você pode querer analisar.

Em outras palavras, se a falha for causada por um erro, corrigir a falha não corrigirá o erro.

E quando o kernel para de desreferenciar um ponteiro nulo, o espaço do usuário pode ser examinado naquele momento para determinar se o problema ainda está presente.

Algumas pessoas apreciam o heads-up...

Onde posso baixar o módulo bcm2835-v4l2 preciso que corresponde a esse rastreamento? Eu conheço o commit do kernel, mas como quero desmontá-lo, quero evitar diferenças de cadeia de ferramentas e opções de compilação.

http://mirror.archlinuxarm.org/armv6h/core/linux-raspberrypi-4.4.9-1-armv6h.pkg.tar.xz

Lembre-se de que as versões mais recentes do GCC fazem um trabalho melhor ao expor o código incorreto que causa esses tipos de problemas. Eu vi problemas semelhantes no código do kernel interno que só foi construído com versões antigas, como 4.9 e anteriores; nunca qualificado contra as versões estáveis ​​atuais.

Essa compilação específica foi contra o GCC 5.3.0, e você pode obter uma cópia da cadeia de ferramentas de compilação cruzada aqui para testar com:
https://archlinuxarm.org/builder/xtools/5.3.0-5/

Quaisquer construções futuras serão construídas com o GCC 6.1.1, que possui uma cadeia de ferramentas cruzada correspondente no subdiretório imediato.

Baixei o arquivo e extraí o módulo, mas não corresponde ao rastreamento - o .ko nem contém o símbolo bm2835_mmal_init.

Os módulos são gzip'd.

nm bcm2835-v4l2.ko | grep bm2835_mmal_init
00000000 t bm2835_mmal_init
00002ce0 T bm2835_mmal_init_controls

Interessante - o objdump na minha cadeia de ferramentas está relatando o nome do alias - init_module.

Se for de fato um componente correspondente, então é uma falha muito estranha. Parece que o endereço de uma variável local ( resolutions ), que foi armazenada na pilha (os dados e um ponteiro para ela), agora é zero (o ponteiro, não os dados).

A linha 1877 parece ser a linha com falha. Nesse ponto, r2 é resolutions (carregado de sp+12 - 00000000), enquanto ip mantém o endereço de resolutions[camera][0] (também zero, porque camera (r6) é zero ).

FYI, aqui está a diferença de configuração entre o kernel do projeto Raspbian e o Archlinux:
https://gist.github.com/kad/bbc59804a9ce640124719979e531ad2a
Kernel binário Raspbian capaz de inicializar e carregar módulo sem problemas (mesmo dispositivo, mesmos gerenciadores de inicialização, mesmo espaço de usuário em ambos os casos de teste, a única diferença é /lib/modules/* e /boot/kernel.img)

@pelwell na linha 1532, há um problema potencial em que a pilha após as resoluções[] seria substituída, devido ao fato de gravar em um índice maior que MAX_BCM2835_CAMERAS (tamanho das resoluções[]). não deveria ser o caso, pois cam_info.num_cameras deveria ser 0 ou 1... mas ainda assim.

Então, o kernel raspbian funciona bem com a imagem do arco?
Ainda funciona se você reconstruí-lo usando ferramentas de arco, mas raspbian .config? Gostaria de saber se a versão do gcc ou os sinalizadores de compilação podem ter um efeito.

O kernel binário de https://github.com/Hexxeh/rpi-firmware funciona em cima da imagem do Arch.
Não tentei reconstruí-lo, pois até agora não há configuração de ambiente de compilação cruzada para esses fins.
Até agora, era apenas um usuário feliz do que um desenvolvedor real para pacotes de arco :)

Também podemos tentar o módulo pré-compilado com uma instalação Raspbian direta.

O kernel usado no Alarm recebeu inúmeras atualizações.
A questão parece permanecer. Alguma notícia sobre isso?

Minha sugestão é que os mantenedores do Arch construam um kernel usando seu compilador e nossa configuração (bcm2709_defconfig).
Se isso funcionar, sugeriria um problema de configuração que pode ser rastreado.
Se isso não funcionar, sugere um problema com as ferramentas (talvez a versão do gcc ou os sinalizadores de compilação).

@pelwell na linha 1532, há um problema potencial em que a pilha após as resoluções[] seria substituída, devido ao fato de gravar em um índice maior que MAX_BCM2835_CAMERAS (tamanho das resoluções[]). não deveria ser o caso, pois cam_info.num_cameras deveria ser 0 ou 1... mas ainda assim.

https://github.com/raspberrypi/linux/blob/rpi-4.4.y/drivers/media/platform/bcm2835/bcm2835-camera.c#L1532

    for (i = 0;
         i < (cam_info.num_cameras > num_resolutions ?
            cam_info.num_cameras :
            num_resolutions);

Sim, pequeno bug - os dois resultados são revertidos.

         i < (cam_info.num_cameras > num_resolutions ?
            num_resolutions :
            cam_info.num_cameras);
);

Portanto, se a GPU retornasse "grande número", você poderia executar o final da matriz, mas, caso contrário, sempre acabaria com valores num_resolutions sendo gravados em resoluções.
@popcornmix Você poderia revisar e criar um patch rápido para mim - não estou em condições de criar um no momento.

Não resultará em uma desreferência de NULL, apenas empilhe o lixo. Isso também implicaria que você tem um firmware/kernel muito parafusado para obter esse lixo de volta da GPU.

Ok empurrou a correção. Concordo que a correção está correta, mas não consigo ver o erro que está causando esse problema, mas pode valer a pena um teste com o Arch.

Essa linha (https://github.com/raspberrypi/linux/blob/rpi-4.4.y/drivers/media/platform/bcm2835/bcm2835-camera.c#L1522) também me incomodou, mas novamente não consegui ver como ele poderia destruir a pilha.

Eu não vejo L1522 tendo um problema.
Está dizendo que no caso de não conseguir criar o componente, acho que há 1 câmera presente. Pode ser melhor definir a resolução[0][] para 2592x1944 também - não há como o imx219 funcionar contra um firmware que não suporta camera_info corretamente, então adivinhe os 5MP do OV5647.
Como alternativa, diga sem câmera (já que será um firmware antigo e com alta probabilidade de falhar) e retorne 0.

O componente camera_info esteve na compilação do firmware provavelmente durante toda a vida útil do Pi. A falha na criação do componente provavelmente resultará na falha de todas as chamadas futuras.

Ainda não há desreferência NULL ou lixo empilhado.

Acabei de ver o que parecem 2 caminhos incorretos de manipulação de erros que podem vazar recursos (mas não travar).
https://github.com/raspberrypi/linux/blob/rpi-4.4.y/drivers/media/platform/bcm2835/bcm2835-camera.c#L1874 deve ser goto free_dev: para que outros nós sejam limpos acima.
A linha 1957 deve ser for ( ; camera >= 0; camera--) caso contrário o índice de dispositivo 0 não será limpo.
Ambos os problemas atingiriam apenas os usuários do módulo de computação, caso contrário, num_cameras seria 1.

Sempre feliz por revisões de código, mas não há voluntários clamando pelo trabalho.

Ah, a mudança de camera >= 0 foi o que eu estava sugerindo aqui:
https://github.com/raspberrypi/linux/pull/1393#discussion_r58740685

Ah a câmera >= 0 mudança era o que eu estava sugerindo aqui: #1393 (comentário)

Desculpas - eu peguei a segunda parte desse comentário, perdi a primeira. :-(

Oi
Eu tenho um problema semelhante com o módulo de câmera raspi, na inicialização recebi um kernel oops.
Talvez esteja relacionado ao seu problema?
Se eu puder ajudar de alguma forma?

Parece que o kernel 4.4.7 funciona. Onde podemos encontrar o antigo arquivo pkg? Eu não tenho no meu cache do pacman (nova instalação). Eu posso ser uma correção temporária.

@ouafnico Arch não é a distribuição suportada - por favor, pergunte onde encontrar pacotes.

Se você ler os detalhes aqui, é apenas o Arch que tem um problema. Até a distribuição Arch com kernel Raspbian funciona.

Existem dois commits em potencial que podem ter causado isso: a980ac51b05f0e0dc275b6be44f00f144af9ab7b (16 de abril) ou 5fe9c7b56989bed7360dc560f18cac7f36c9a7d4 (8 de abril). A inspeção de ambos não mostra problemas óbvios.
Este repositório linux passou de 4.4.8 em 20 de abril e para 4.4.7 em 12 de abril, o que indicaria a980ac5. Como isso gerencia um deref de ponteiro nulo não é óbvio.

As chamadas para vchiq podem ser potencialmente afetadas pela presença/ausência de CONFIG_OABI_COMPAT ?
Essa é a parte mais suspeita que encontrei até agora na diferença entre as configurações do Arch e do Raspbian.

Estava funcionando no 4.4.7 mas se não me engano o CONFIG_OABI_COMPAT estava na configuração também para esta versão.

É verdade que essa opção de configuração durou muito tempo. Mas o novo código que hoje em dia consulta a resolução da câmera pode expor isso, se minha suspeita estiver correta.

o 4.4.11-4 está funcionando?

Não, desculpe. Assim que eu modprobe o módulo o RPi não é mais alcançável.

Não, infelizmente continua travando :(

[root<strong i="6">@campi</strong> kad]# uname -a
Linux campi 4.4.11-4-ARCH #1 Tue May 31 19:50:35 MDT 2016 armv6l GNU/Linux
[root<strong i="7">@campi</strong> kad]# modprobe bcm2835-v4l2
Segmentation fault
[root<strong i="8">@campi</strong> kad]# dmesg 
[   69.272269] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[   69.280589] pgd = d30a4000
[   69.283483] [00000000] *pgd=156ed831, *pte=00000000, *ppte=00000000
[   69.290006] Internal error: Oops: 17 [#1] ARM
[   69.294448] Modules linked in: bcm2835_v4l2(+) videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core v4l2_common videodev media cfg80211 i2c_bcm2708 spi_bcm2835 bcm2835_gpiomem bcm2835_wdt uio_pdrv_genirq uio sch_fq_codel bcm2835_rng rng_core ip_tables x_tables ipv6
[   69.319752] CPU: 0 PID: 632 Comm: modprobe Not tainted 4.4.11-4-ARCH #1
[   69.326476] Hardware name: BCM2708
[   69.329944] task: d3003580 ti: d5480000 task.ti: d5480000
[   69.335524] PC is at bm2835_mmal_init+0x78/0x768 [bcm2835_v4l2]
[   69.341547] LR is at 0x0
[   69.344136] pc : [<bf1c8078>]    lr : [<00000000>]    psr: a0000113
               sp : d5481d98  ip : 00000000  fp : bf1c4688
[   69.355791] r10: 00000000  r9 : bf1c439c  r8 : 00000000
[   69.361105] r7 : bf1c8000  r6 : 00000000  r5 : 00000000  r4 : d6b1c800
[   69.367738] r3 : bf1c364c  r2 : 00000000  r1 : 00000000  r0 : d6b1c800
[   69.374371] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[   69.381624] Control: 00c5387d  Table: 130a4008  DAC: 00000055
[   69.389935] Process modprobe (pid: 632, stack limit = 0xd5480188)
[   69.398686] Stack: (0xd5481d98 to 0xd5482000)
...
[   69.707458] [<bf1c8078>] (bm2835_mmal_init [bcm2835_v4l2]) from [<c00094e8>] (do_one_initcall+0x80/0x1d8)
[   69.725075] [<c00094e8>] (do_one_initcall) from [<c00d05a8>] (do_init_module+0x5c/0x1a8)
[   69.741113] [<c00d05a8>] (do_init_module) from [<c007c960>] (load_module+0x1ac0/0x1fec)
[   69.756997] [<c007c960>] (load_module) from [<c007cfac>] (SyS_init_module+0x120/0x144)
[   69.772754] [<c007cfac>] (SyS_init_module) from [<c000ee00>] (ret_fast_syscall+0x0/0x34)
[   69.788592] Code: 0a000174 e59d200c e59f3664 e082e186 (e792c186)
[   69.798911] ---[ end trace 97f95d643ae9c613 ]---

Para esclarecer isso: raspistill está fazendo imagens absolutamente boas. Portanto, hardware e conexão não são o problema.

4.4.12-1-ARCH, câmera e bcm2835_v4l2 funcionam novamente.

Posso confirmar: funciona novamente também para mim.

Bug pode ser fechado.

Sabemos o que foi alterado para corrigi-lo?

O kernel do Arch foi movido de 37b930adffa15bfaa9b3ffb83e021afff31bb3d5 para e64101f36454e54b877fde44ed866320636e590b

@popcornmix , então eu suspeito que este "bcm2835-camera: Corrija o erro max/min ao fazer um loop sobre câmeras/resoluções". Talvez algo além...

Você pode realmente usar o dispositivo de vídeo depois que o módulo for carregado?
Eu tentei várias maneiras de criar fluxos usando o VLC, mas o cliente parece não obter nenhum dado e não consegue preencher seu buffer. Tentei HTTP e RTSP.

O movimento parece ser capaz de usar o dispositivo, mas também maximiza a CPU para que a taxa de quadros seja terrível.

Ignorar o dispositivo v4l2 e canalizar raspivid através do VLC funciona, então não acho que configurei errado. Isso dá um atraso de vários segundos embora.

@TwoD MJPGStreamer com 4.4.12 funciona para mim.

@kad Bem, o MJPGStreamer funciona, mas não usa o dispositivo v4l2, portanto não precisa do módulo do kernel bcm2835_v4l2.

no meu caso, o mjpgstreamer está usando v4l:

mjpg_streamer -i input_uvc.so -d /dev/video0  -r 1280x720 -f 15 -o output_http.so -p 8090 -w /usr/share/mjpeg-streamer/www/

@kad De onde você tirou essa versão? O que eu tenho (https://github.com/jacksonliam/mjpg-streamer) não reconhece o argumento -d.
Seu upstream parece conter outra versão do mjpg_streamer (sem "-experimental"). Ele menciona algo sobre ser possível compilar com suporte a V4L2, mas nenhum argumento -d. A documentação parece praticamente inútil. :/

@kad Não importa, eu consegui trabalhar com essa versão, estava usando o módulo de entrada errado. Obrigado pela dica. Não tenho certeza por que ainda não funcionará com o VLC, mas isso prova que o dispositivo deve estar funcionando.

(Para o registro, o comando acima está sem aspas. Deve ser mjpg_streamer -i "input_uvc.so -d /dev/video0 -r 1280x720 -f 15" -o "output_http.so -p 8090 -w /path/to/mjpg_streamer/www" )

A versão que uso é a versão antiga e original de 2009: https://aur.archlinux.org/packages/mjpg-streamer Não contém nenhum outro driver de entrada além do uvc. Os garfos mais novos têm outros drivers e argumentos um pouco diferentes. Mas apenas para verificar o funcionamento do módulo, você pode usar v4l2-ctl para consultar os parâmetros da câmera pelo menos

Isso parece estar levantando a cabeça novamente, de uma maneira ligeiramente diferente:
https://archlinuxarm.org/forum/viewtopic.php?f=15&t=11354&p=54830#p54823

Os usuários o rastrearam especificamente para bcm2835_v4l2 & bm2835_mmal_init no que parece ser https://github.com/raspberrypi/linux/blob/204050d0eafb565b68abf512710036c10ef1bd23/drivers/media/platform/bcm2835/bcm2835-camera.c #L1901

http://lists.infradead.org/pipermail/linux-rpi-kernel/2017-March/005741.html apontou um memcpy potencialmente desonesto na sondagem dos parâmetros da câmera.
Estou investigando, mas à primeira vista parece que a pessoa que reimplementou o MMAL dentro do kernel não o combinou.
https://github.com/raspberrypi/userland/blob/master/interface/mmal/vc/mmal_vc_api.c#L1187
!=
https://github.com/raspberrypi/linux/blob/rpi-4.9.y/drivers/media/platform/bcm2835/mmal-vchiq.c#L1307

Qualquer incompatibilidade no tamanho do parâmetro é um erro mais acima, mas não estou vendo nada óbvio imediatamente.
https://github.com/raspberrypi/userland/blob/master/interface/mmal/mmal_parameters_camera.h#L526 parece corresponder a https://github.com/raspberrypi/linux/blob/rpi-4.9.y/drivers/ media/platform/bcm2835/mmal-parameters.h#L682 , e tanto o firmware quanto o userland usam o primeiro deles. Algumas impressões de depuração de sizeof(struct) são solicitadas.

BTW, também notei que a função no kernel tem algum código estranho para adicionar 8 bytes ao tamanho que envia para o firmware.

static int port_parameter_get(struct vchiq_mmal_instance *instance,
struct vchiq_mmal_port *port,
u32 parâmetro_id, void *valor, u32 *valor_tamanho)
{
int ret;
struct mmal_msg m;
struct mmal_msg *rmsg;
VCHI_HELD_MSG_T rmsg_handle;

    m.h.type = MMAL_MSG_TYPE_PORT_PARAMETER_GET;

    m.u.port_parameter_get.component_handle = port->component->handle;
    m.u.port_parameter_get.port_handle = port->handle;
    m.u.port_parameter_get.id = parameter_id;
    m.u.port_parameter_get.size = (2 * sizeof(u32)) + *value_size;

@ 6by9 Eu acredito que isso pode ser fechado? Só quero verificar novamente.

Sim, pode ser fechado.