<p>linux-raspberrypi-4.19.57-2, 4.19.58-1, 4.19.59-1, 4.19.63-1 causa kernel panic em raspberry pi 2 (arch linux arm)</p>

O problema pode estar relacionado a # 3084,
e uma vaga suspeita de que também se relaciona com # 2239

Necessita de mais informações:

• O que ocorre no kernel panic (por favor, um dump do console ou pelo menos uma foto)
• Onde está localizado o seu cartão SD ou dispositivo USB rootfs?

O rootfs está localizado na unidade flash USB (8 GB),

(Cartões de memória (qualquer um) não eram confiáveis ​​para root em caso de falha de energia (desde a compra))

Vou tentar tirar uma foto do kernel panic.

A seguir está a imagem do log de inicialização, pouco antes do kernel panic

@lategoodbye Os dados acima são os solicitados (espero),

Atualmente, tenho retido a atualização:

linux-raspberrypi: ignoring package upgrade (4.19.57-1 => 4.19.58-1)

Porque também é o servidor principal em casa e,
recuperar-se do kernel panics é um processo demorado e perturbador,

no entanto, posso tentar causar intencionalmente o kernel panic atualizando o software,
se necessário.

Eu tenho um raspberry 3b e a mesma coisa acontece com o kernel 4.19.58-1 no arch linux arm.

Eu tenho o sistema / em um disco USB e isso me dá kernel panic. Além disso, se eu instalar todo o sistema em um cartão SD e tentar montar dispositivos USB com esta versão do kernel, recebo print_req_error e erros de E / S.

Com as versões anteriores do kernel funciona perfeitamente.

Eu tenho um Raspberry Pi 3B + com Arch Linux em um cartão SD. Com o kernel 4.19.58 meu sintonizador USB Sundtek não está mais funcionando. Com 4.19.57 tudo funciona conforme o esperado. Talvez haja algo de ruim em geral com dispositivos 4.19.58 e USB? Se você precisar de mais informações, por favor, pergunte.

@nightBulb Obrigado pela foto. Parece que o dispositivo USB não está acessível (-110 = ETIMEDOUT).

Mas um traço do verdadeiro kernel panic ainda seria necessário.

@lategoodbye Este é o rastreamento de pilha do kernel panic, (espero que seja necessário)

Também descobri que linux-raspberrypi-4.19.57-2 também causa, o que parece ser o mesmo problema.
(Pânico no kernel e tudo ...)

linux-raspberrypi-4.19.57-1 parece ser o último kernel são.

E assim, mudar o título parece apropriado.

@nightBulb Desculpe por ser impreciso, precisamos do início do kernel panic.

Além disso, seu problema se parece com o # 3067

@lategoodbye Existe algum lugar onde o Bootlog é armazenado,
fazer com que a parte inicial do kernel panic rola para cima rapidamente na tela ...

ou qualquer outro método além de tirar fotos para obter o log de inicialização?

Além disso, linux-raspberrypi-4.19.57-1 está inicializando bem, ao contrário do # 3067.

Sem rootfs, há chance de armazenar o arquivo.

A melhor solução é conectar o adaptador TTL serial ao UART de depuração.

Caso o USB ainda funcione, você pode tentar aumentar o buffer de registro do kernel adicionando log_buf_len=1M ao cmdline.txt

@lategoodbye Eu quis dizer, como você rola a tela após o kernel panic?

Também não tenho um adaptador TTL.

Porém, uma coisa a ser observada, antes da inicialização, se eu remover o rootfs USB, o bootloader (ou seja lá o que for que inicialize o rpi) me leva ao terminal ash.

depois de inserir novamente o USB do rootfs e chamar o init, entra em pânico e não consigo mais executar nenhum comando, mesmo a partir do bootloader ash 😁

O pânico acima é com 4.19.58-1

Às vezes, é possível rolar para trás via página para cima / para baixo. Mas isso depende do acidente.

As teclas (shift +) Page up / down não parecem estar funcionando, especialmente após o kernel panic,

Eu até tentei o seguinte,

• Remova a unidade flash USB que contém a raiz
• reinício
• o processo de inicialização cai para ash
• Reinsira a unidade flash USB contendo a raiz
• execute ./init script em rootfs terminal (cinza)
• aguarde a ocorrência de reset high speed USB device using dwc_otg mensagem de erro / kernel
• sair (digitando exit na tela)
• kernel panic

Nenhum método para rolar a tela.

Adicionar framebuffer_height=2160 ao config.txt obterá o dobro de linhas na tela.

Aqui está um log do console mostrando o problema. É de um Pi2 v1.1 rodando Arch Linux, com o diretório / boot no SD e o sistema operacional em um SSD conectado via USB - o Toshiba HDD mencionado no log é apenas a interface usb-sata.

Tive um problema semelhante com outro Pi2 v1.2 que é usado como um servidor TVHeadend; o sistema operacional está em SD, mas os vídeos estão em um HDD USB. Com este dispositivo não há travamento, mas a reprodução do vídeo para depois de um tempo e o disco fica inacessível até que o Pi seja reinicializado.

O software mais recente que sei que está funcionando é o Linux 4.19.55 e o bootloader / firmware 20190624.

minicom.txt

Eu também consegui entender o kernel panic usando a ideia de @pelwell .

Eu também tenho mais fotos do mesmo kernel panic, se esta não estiver clara, posso carregá-las se necessário.

A imagem acima aparece reta quando clicada, ela é girada na visualização.

Estou vendo o mesmo bug no Raspberry Pi 3 Modelo B, inicializando de um SSD USB externo.
kernel-4.19.58-1-ARCH-boot-from-usb-device-fail.txt

Os fatores comuns aqui parecem ser a versão do kernel e o Arch Linux - não é um problema que vimos no Raspbian, e seria esclarecedor se um de vocês instalasse o Raspbian em uma placa sobressalente para confirmar (ou não) se ele inicializa bem .

OK, instalei o Raspbian Buster Lite atual em um RPi3 (kernel 4.19.57-V7 +) e configurei-o para inicializar do SD, mas use um SSD como FS raiz. Em seguida, executei um dist-upgrade que atualizou o kernel para 4.19.58. O sistema inicializou normalmente. Mudei o cartão SD e o SSD para o mesmo RPi2 do meu teste anterior e ele continuou a inicializar corretamente. Não é exatamente o mesmo teste (o SSD e a interface usb-sata eram diferentes), mas sugere um problema do Arch.

Os fóruns do Arch têm uma postagem com o mesmo problema:
https://archlinuxarm.org/forum/viewtopic.php?f=60&t=13792

minicom2.txt

Eu tenho iterado sobre os parâmetros de configuração do kernel que o kernel do Arch mudou recentemente. Veja diff aqui . Não tenho 100% de certeza se estou no caminho certo, mas me parece que CONFIG_VMSPLIT_3G = y (em vez de VMSPLIT_2G) é a mudança que dispara o bug para mim no RPI3.

Os especialistas aqui podem negar ou confirmar que isso pode fazer com que a inicialização USB não funcione?

Notificando também @kmihelich da equipe ARM do Arch Linux.

Eu construí um novo kernel Foundation de estoque (que agora está na versão 4.19.59) e ele inicializa meu Arch RPi3 com rootfs em SSD. Este parece ser um problema de configuração do kernel do Arch.

A criação do Pi2 foi há muito tempo, mas pelo que me lembro, mudamos para o VMSPLIT_2G para evitar a necessidade do HIGHMEM em uma peça de 1 GB. A configuração do Arch tem HIGHMEM habilitado?

De https://archlinuxarm.org/packages/armv7h/linux-raspberrypi/files/config.v7 (também config.v6)
CONFIG_HIGHMEM = y

Alterar para CONFIG_HIGHMEM = n parece resolver o problema também.

Alterar para CONFIG_HIGHMEM = n parece resolver o problema também.

Isso não é uma correção, é apenas uma solução alternativa.

Sim, eu concordo, desculpe pelo texto incorreto.

Esta não é a minha área, mas apenas no caso de ser relevante: a configuração do Arch ativa também CONFIG_ARM_LPAE e CONFIG_ARCH_DMA_ADDR_T_64BIT que resulta em typedef u64 dma_addr_t . Curiosamente, durante a compilação, vejo alguns avisos do driver dwc_otg , por exemplo

drivers/usb/host/dwc_otg/dwc_otg_fiq_fsm.c: In function ‘fiq_increment_dma_buf’:
drivers/usb/host/dwc_otg/dwc_otg_fiq_fsm.c:243:30: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
  struct fiq_dma_blob *blob = (struct fiq_dma_blob *) st->dma_base;
                              ^
drivers/usb/host/dwc_otg/dwc_otg_fiq_fsm.c:252:14: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  hcdma.d32 = (dma_addr_t) &blob->channel[n].index[i].buf[0];
              ^
drivers/usb/host/dwc_otg/dwc_otg_fiq_fsm.c: In function ‘fiq_iso_out_advance’:
drivers/usb/host/dwc_otg/dwc_otg_fiq_fsm.c:292:30: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
  struct fiq_dma_blob *blob = (struct fiq_dma_blob *) st->dma_base;
                              ^
drivers/usb/host/dwc_otg/dwc_otg_fiq_fsm.c:304:14: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  hcdma.d32 = (dma_addr_t) blob->channel[n].index[i].buf;
              ^

O resto dos avisos estão aqui

@tsaarni A motivação por trás das mudanças de configuração foi a introdução do Raspberry Pi 4. Portanto, uma solução temporária seria uma configuração separada para BCM2711. Mas é possível que os caras do Arch não queiram manter outra imagem.

Eu acabei de verificar,
o problema também existe no Linux 4.19.59-1-Arch,

o seguinte é o kernel panic para linux-raspberrypi-4.19.59-1

@kmihelich qual a sua opinião sobre a situação? Pode não haver conserto tão cedo. Seria razoável introduzir outro pacote de kernel Arch com configuração antiga como uma solução alternativa para aqueles que precisam inicializar a partir de dispositivos USB?

Ou talvez introduza um novo pacote experimental CONFIG_HIGHMEM = y para RPi4.

Estou enfrentando o mesmo problema no meu raspberry Pi 2 com archlinuxarm & kernel 4.19.59, depois de atualizar antes que o rPi4 fosse levado em consideração nos pacotes arch. Estou inicializando de um array RAID de 4 pen drives + cartão SD.

No meu caso, consigo inicializar (sem aqueles erros de USB) quando uso 256m de RAM de GPU (ou mais). Diminuir um pouco (192, 160, 128 ...) às vezes causa uma falha na inicialização de uma CPU aleatória (apenas 3 framboesas aparecem no meu monitor de depuração e o processo de inicialização trava mais do que eu posso esperar tentando acordar a CPU) .

Ao fazer o downgrade do meu sistema para as versões anteriores à atualização (não me lembro qual), tudo funciona bem.

Estou enfrentando o mesmo problema no meu raspberry Pi 2 com archlinuxarm & kernel 4.19.59, depois de atualizar antes que o rPi4 fosse levado em consideração nos pacotes arch. Estou inicializando de um array RAID de 4 pen drives + cartão SD.

No meu caso, consigo inicializar (sem aqueles erros de USB) quando uso 256m de RAM de GPU (ou mais). Diminuir um pouco (192, 160, 128 ...) às vezes causa uma falha na inicialização de uma CPU aleatória (apenas 3 framboesas aparecem no meu monitor de depuração e o processo de inicialização trava mais do que eu posso esperar tentando acordar a CPU) .

Ao fazer o downgrade do meu sistema para as versões anteriores à atualização (não me lembro qual), tudo funciona bem.

Defina minha GPU para 256m, é uma solução alternativa. Obrigado @zertyz

Posso confirmar isso,
definir gpu_mem=256 em /boot/config.txt permite que o sistema inicialize normalmente com o kernel atualizado
: +1:: +1:,

(Eu testei com 4.19.59-1 , que é o último no momento do teste)

mas, isso deixa cerca de 742MB ( 998M (mem total) - 256M (mem gpu) ) de memória para os SO e programas restantes: -1:: -1
o que deixa cerca de 500 MB de RAM utilizável para programas de usuário.

executar RPi sem cabeça (por exemplo, como um servidor doméstico) com 256M para GPU é um sério desperdício de RAM (já restrita).

Posso confirmar isso,
definir gpu_mem=256 em /boot/config.txt permite que o sistema inicialize normalmente com o kernel atualizado
+1 +1,

(Eu testei com 4.19.59-1 , que é o último no momento do teste)

mas, isso deixa cerca de 742MB ( 998M (mem total) - 256M (mem gpu) ) de memória para o SO e programas restantes -1 -1,
o que deixa cerca de 500 MB de RAM utilizável para programas de usuário.

executar RPi sem cabeça (por exemplo, como um servidor doméstico) com 256M para GPU é um sério desperdício de RAM (já restrita).

Definitivamente precisamos de uma correção para este. Atualmente, esta é apenas uma solução alternativa, o que é bastante inaceitável por muitas razões.

Interessante. Isso deve nos dar informações suficientes para rastreá-lo, claramente algo está tentando alocar MUITA memória na inicialização e falhando. Framebuffers? Talvez tente max_framebuffers = 0 se estiver executando sem controle?

Será algo a ver com HIGHMEM - com VMSPLIT_3G o kernel não tem faixa de endereço suficiente para chegar a toda a memória. Temos uma configuração para Pi 2/3 que funciona, e os desenvolvedores do Arch parecem ter tentado fazer com que todos os dispositivos compartilhem (pelo menos parte) da configuração Pi4 e a quebraram.

Postagem no archlinux-arm, relacionado com este problema:
https://archlinuxarm.org/forum/viewtopic.php?f=60&t=13821

Alguém sabe se o problema foi corrigido?
O changelog do novo kernel:

https://archlinuxarm.org/packages/armv7h/linux-raspberrypi/log?id=991876d8084a43c69a82aed88d0c03aeae8bea12

Não por essa lista de mudanças, não.

Posso confirmar que a linha gpu_mem = 256 evita o Kernelpanic mas ao atualizar o Sistema usando pacman -Syu haverá um novo problema. Após a reinicialização, o Raspberry Pi para de inicializar completamente e a tela permanece preta, LED verde aparece por cerca de 5 segundos e depois pisca algumas vezes.

O mesmo problema aparece ao atualizar o Raspbian Buster em uma unidade USB e também ao atualizar o Stretch para o novo firmware.

Dispositivo: Raspberry Pi 3 B + (1,3 Reino Unido)
Unidade: Sandisk Ultra 64 Gb / Intenso Aluline 16 GB

Todos os Imges funcionam sem problemas quando transferidos para cartões SD. Logs não são possíveis porque o Pi nem mesmo inicializa no Rainboscreen, desculpe.

O Raspberry Pi 3 B inicializa a unidade sem problemas, então acho que há algum problema no novo firmware ou Bootloader dos arquivos Raspberry Pi do 3 B +.

Atualização: linux-raspberrypi-4.19.63-1 também causa pânico no kernel: -1:: -1:.

com semelhante
reset high speed usb device using dwc_otg
Error Read 64/ ... erro

Acabei de atualizar o comentário principal deste problema com contexto adicional e links para fóruns ARM do Arch Linux

Alguém pode confirmar a observação de @erikschreier de que o problema também afeta o Raspbian?

E problema com a solução alternativa gpu_mem=256 .

Apenas uma atualização linux-raspberrypi- 4.19.65-1 -armv7h ainda tem (/ causa ... ???) kernel panic.
@kmihelich @pelwell

Existe alguma outra solução / solução alternativa além de desperdiçar 256 MB de RAM em um dispositivo de 997 MB de RAM
OU
permanecer em uma versão mais antiga do kernel (provavelmente um risco de segurança ...)

A solução é a mesma de sempre - os desenvolvedores do Arch para descompactar sua configuração Pi 2. Ou execute o Raspbian.

Ainda estou à espera de uma solução ... espero que nos próximos dias.

Você não pode usar um de nossos kernels com o userland do Arch?

A solução é a mesma de sempre - os desenvolvedores do Arch para descompactar sua configuração Pi 2. Ou execute o Raspbian.

O problema parece não estar relacionado com a configuração do Pi 2 do archlinuxarm, já que também acontece no Raspbian, como relatado alguns posts atrás e verificado por mim, no meu Pi 2 - Inicializando o raspbian do MMC, mas com drives USB acoplados é o suficiente para revelar o problema - mesmo se as unidades USB não estiverem envolvidas no processo de inicialização.

Talvez o título desta edição deva ser reconsiderado e a parte do Archlinuxarm removida?

@zertyz , o problema com USB também acontece com o raspbian? Informação relevante!
Estou usando o archlinux-arm em um rpi3b, não tenho problemas com o kernel panic, mas minhas portas USB não podem mais acessar as unidades, se eu tentar, recebo muitos erros.

Já resolvemos esse problema aqui. Está relacionado ao driver USB e é acionado pelas definições de configuração do kernel CONFIG_VMSPLIT_3G = y e CONFIG_HIGHMEM = y. O problema apareceu quando essas configurações foram colocadas em uso no kernel Arch raspberry por solicitamos comentários (veja diff aqui ).

Ninguém parece estar trabalhando com suporte HIGHMEM para o driver USB. Portanto, como sugerido aqui antes, a única maneira viável de avançar parece ser reverter a mudança no pacote do kernel do Arch raspberry ou mudar para uma distro Linux diferente.

Eu vim aqui depois de ver isso com archlinuxarm e kernel 4.19.65.
Inicializar com gpu_mem=256 torna o kernel capaz de inicializar.

Encontrei esses problemas mais antigos que podem estar relacionados a CONFIG_HIGHMEM=y e CONFIG_VMSPLIT_3G=y :

https://github.com/raspberrypi/linux/issues/1641

E alguns ainda mais antigos:

https://github.com/raspberrypi/linux/issues/1394

A solução é a mesma de sempre - os desenvolvedores do Arch para descompactar sua configuração Pi 2. Ou execute o Raspbian.

@pelwell - Verifique seu e-mail para nossa troca por volta de 12 de julho. Minha memória é que para fazer o RPi4 inicializar, foram necessárias as alterações no arquivo de configuração que @tsaarni vinculou.

Pelas minhas anotações, eram estas 3:
1) "Tipo de sistema> Seleção de plataforma múltipla" para desativar "plataformas baseadas em ARMv6 (ARM11)"
2) Habilitar LPAE
3) Selecione uma divisão 1G / 3G

Não me lembro se a opção HIGHMEM está selecionada para fazer isso ou não.

Não tenho certeza do que você está dizendo. O problema é sobre por que as imagens atuais do Arch não rodam no Pi 2, e você acabou de descrever o que tivemos que fazer no Pi 4. Observe que o Pi 4 usa um controlador USB completamente diferente, portanto, os problemas relatados aqui com o driver dwc_otg e HIGHMEM não se aplicam.

@pelwell - Achei que a hipótese é que o problema para RPi2 foi introduzido quando o Arch ARM fundiu essas opções de suporte, incluindo HIGHMEM para permitir o suporte RPi4.

Já resolvemos esse problema aqui. Está relacionado ao driver USB e é acionado pelas definições de configuração do kernel CONFIG_VMSPLIT_3G = y e CONFIG_HIGHMEM = y. O problema apareceu quando essas configurações foram colocadas em uso no kernel Arch raspberry por solicitamos comentários (veja diff aqui ).

Ninguém parece estar trabalhando com suporte HIGHMEM para o driver USB. Portanto, como sugerido aqui antes, a única maneira viável de avançar parece ser reverter a mudança no pacote do kernel do Arch raspberry ou mudar para uma distro Linux diferente.

Eu pensei que a hipótese é que o problema para RPi2 foi introduzido quando o Arch ARM fundiu essas opções de suporte, incluindo HIGHMEM para permitir o suporte RPi4.

Sim, essa é a hipótese. Ainda não entendi seu ponto - você apenas parece estar reafirmando o problema.

Sim, essa é a hipótese. Ainda não entendi seu ponto - você apenas parece estar reafirmando o problema.

Se desativarmos o HIGHMEM, haverá algum efeito negativo para as placas Pi4? Se não, seria um bom teste ter alguém com Arch ARM e um RPi2 afetado compilando o kernel atual usando o seguinte patch que desabilita HIGHMEM e ver se ele corrige o problema de USB?

https://gist.github.com/graysky2/5dee027e153fadc98659a85f32aeddbc

Em caso afirmativo, e se o Pi4 puder ser executado sem efeitos nocivos, a mudança pode ser proposta.

Se desativarmos o HIGHMEM, haverá algum efeito negativo para as placas Pi4?

Sim - o kernel não será capaz de endereçar toda a memória e pode até travar - não me lembro do mecanismo de falha preciso.

@pelwell - OK. Ainda sinto que se um usuário RPi2 afetado tentar compilar / inicializar com aquele HIGHMEM desabilitado com patch de configuração, será um teste de que está causando o problema. Em caso afirmativo, o Arch ARM pode precisar considerar outro pacote de kernel para RPi2 com HIGHMEM desabilitado, não?

@ graysky2 Eu testei com RPi3 anteriormente por aqui e corrigiu o problema com o driver dwc_otg.

Além disso, não estou recebendo um kernel panic por meio de um Pi 3, mas os dispositivos USB não funcionam após 4.19.57-1.

Em 13 de agosto de 2019. às 21h47, Phil Elwell [email protected] escreveu:

Eu pensei que a hipótese é que o problema para RPi2 foi introduzido quando o Arch ARM fundiu essas opções de suporte, incluindo HIGHMEM para permitir o suporte RPi4.

Sim, essa é a hipótese. Ainda não entendi seu ponto - você apenas parece estar reafirmando o problema.

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, vê-lo no GitHub https://github.com/raspberrypi/linux/issues/3087?email_source=notifications&email_token=AAHLD4CJ5EDDIIJ6Z4CL7LLQEMFUHA5CNFSM4IFAERI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4GYT2A#issuecomment-520980968 , ou silenciar o fio https://github.com/notifications/ unsubscribe-auth / AAHLD4GN2V5AQMRRHJCMSP3QEMFUHANCNFSM4IFAERIQ .

Sinto muito, não li todos os mais de 50 comentários. Meu objetivo é ajudar verificando qual é a correção correta e, potencialmente, enviar um PR ao Arch ARM para corrigi-lo. Parece que desativar o HIGHMEM não é uma solução para alguns dos comentários acima. Eu entendi isso corretamente?

Defina o VMSPLIT de volta para 2G e, em seguida, desative HIGHMEM e LPAE porque nenhum deles é necessário.

Sem problemas. Sua ajuda é muito apreciada.
Ainda não testei com o patch postado, mas de acordo com um post anterior, parece que ele corrigiu problemas de USB no Pi 3.

Em 2019. 13 de agosto, às 22:08, graysky [email protected] escreveu:

Sinto muito, não li todos os mais de 50 comentários. Meu objetivo é ajudar verificando qual é a correção correta e, potencialmente, enviar um PR ao Arch ARM para corrigi-lo. Parece que desativar o HIGHMEM não é uma solução para alguns dos comentários acima. Eu entendi isso corretamente?

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, vê-lo no GitHub https://github.com/raspberrypi/linux/issues/3087?email_source=notifications&email_token=AAHLD4ELTUTQXLHAEFZ75DLQEMIDRA5CNFSM4IFAERI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4G2RRY#issuecomment-520988871 , ou silenciar o fio https://github.com/notifications/ unsubscribe-auth / AAHLD4BJN647OS6TH5ORGDDQEMIDRANCNFSM4IFAERIQ .

@pelwell -

• "Tipo de sistema> Seleção de plataforma múltipla" para desativar "plataformas baseadas em ARMv6 (ARM11)"
• Habilitar LPAE
• Selecione uma divisão 1G / 3G

Estou confuso sobre isso ... na troca de e-mail que você mencionou, o LPAE era necessário para inicializar o RPi4, pelo que me lembro. Você está dizendo com 2 pacotes de kernel separados?

1) Permaneça como está para RPi4
2) VMSPLIT de volta para 2 G e desabilite HIGHMEM para RPi2

Sim - é isso que usamos.

Observo um problema semelhante no RPI3 :( Quando haverá correções oficiais?

linux-raspberrypi-4.19.57-2

[   11.694847] usb 1-1.2: reset high-speed USB device number 5 using dwc_otg
[   11.964878] usb 1-1.2: reset high-speed USB device number 5 using dwc_otg
[   12.234876] usb 1-1.2: reset high-speed USB device number 5 using dwc_otg
[   12.504872] usb 1-1.2: reset high-speed USB device number 5 using dwc_otg
[   12.635410] sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00
[   12.640593] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 00 00 00 00 00 f0 00
[   12.645834] print_req_error: I/O error, dev sda, sector 0
[   12.744877] usb 1-1.2: reset high-speed USB device number 5 using dwc_otg
[   13.014874] usb 1-1.2: reset high-speed USB device number 5 using dwc_otg
[   13.284848] usb 1-1.2: reset high-speed USB device number 5 using dwc_otg
[   13.554853] usb 1-1.2: reset high-speed USB device number 5 using dwc_otg
[   13.824870] usb 1-1.2: reset high-speed USB device number 5 using dwc_otg
[   14.094896] usb 1-1.2: reset high-speed USB device number 5 using dwc_otg
[   14.225416] sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00
[   14.229493] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 00 00 f0 00 00 10 00
[   14.233534] print_req_error: I/O error, dev sda, sector 240

Archlinux

Eu imagino que os desenvolvedores do Arch terão alguns problemas de empacotamento para resolver a fim de oferecer suporte a uma construção de kernel extra, então espere um pouco.

Vocês sabiam que se você trocar a placa por um RPI4, o mesmo erro ocorre aleatoriamente em vários pontos (logo após a inicialização ou mais tarde) no tempo com essas versões de kernel e a configuração USB para drives? Menos os erros dwc_otg, o resto é o mesmo. Resultando em kernel panic, eventualmente.

@nightBulb @ johnny-cash @dkadioglu @ dave-p @tsaarni @esiqveland @Flameborn @denisandroid - Atualize seus sistemas com um espelho insync e veja se o problema desapareceu:

https://github.com/archlinuxarm/PKGBUILDs/commit/274a92b52517b943eccb82ed7115801765547a75
https://github.com/archlinuxarm/PKGBUILDs/commit/dd119141f880c1ead5290b7141364da2dea3353b

Se você estiver executando um Pi4, tome medidas com base no aviso do pacman:

:: Processing package changes...
(1/4) upgrading linux-raspberrypi                                            [############################################] 100%
________________________________________________________________________________

WARNING: You must switch to a different kernel for the Raspberry Pi 4:
         pacman -S linux-raspberrypi4
________________________________________________________________________________

Posso confirmar que meu pi3 está inicializando novamente com gpu_mem=32

usando o pacote de kernel atualizado linux-raspberrypi-4.19.66-1 .

@ graysky2
Eu também posso confirmar que linux-raspberrypi-4.19.66-1-armv7h corrige o kernel panic em R-Pi 2
: +1:: +1:: +1:

embora, observe que:
Após a inicialização e login completos, havia um único

[ 13.457124] usb 1-1.4.2: device descriptor read/64, error -110

erro na saída de dmesg , embora isso pareça ocorrer também em 4.19.57-1 .

Se for corrigido para outros também, recomendo que este problema seja resolvido. : 1st_place_medal:

Obrigado. 😊

Funciona .. No entanto, teve problemas com o NFS Server. Eu estava recebendo os erros de tag 0x2003 durante a inicialização do nfs-server. Tive que desabilitar o serviço nfs-server, reiniciar, habilitar e iniciar o serviço. As reinicializações subsequentes parecem boas. Portanto, o NFS Server precisa de uma atualização após esse problema. Em um RPI2.

Atualizações para Archlinux (RPI 3)

Пакеты (11) dbus-1.12.16-2  git-2.22.1-1  linux-firmware-20190815.07b925b-1  linux-raspberrypi-4.19.66-1
linux-raspberrypi-headers-4.19.66-1  llvm-libs-8.0.1-2  raspberrypi-bootloader-20190816-1
raspberrypi-bootloader-x-20190816-1  systemd-242.84-2  systemd-libs-242.84-2
systemd-sysvcompat-242.84-2

To be downloaded: 144.67 MiB
To be installed: 686.54 MiB
Resizing: 1.66 MiB

Novo kernel: 4.19.66-1
Núcleo do problema: 4.19.65-1

_Erros ao trabalhar com usb não são observados. 'Dmesg' está vazio._

dd bs=1M count=256 if=/dev/zero of=/tmp/sdb/test.img oflag=direct
256+0 записей получено
256+0 записей отправлено
268435456 байт (268 MB, 256 MiB) скопирован, 31,3382 s, 8,6 MB/s

@pelwell - Provavelmente seguro fechar isto.