Linux: Pi3B +: problema de transferência de arquivos USB + ethernet
Oi,
Tenho problemas ao transferir arquivos de um HDD externo USB ou unidade flash USB conectada no novo RPi 3B + para outro computador via SFTP ou samba. Após a transferência de uma quantidade aleatória de dados, a taxa de transferência cai para 0 e permanece assim por pelo menos 30 minutos (cancelei a transferência após esse tempo).
Não consigo ver nenhum erro nos logs do sistema padrão do raspbian. Estou executando o raspbian stretch com as últimas atualizações, também fiz uma atualização de firmware com rpi-update.
O RPi 3B + é alimentado com uma fonte oficial de framboesa (2,5A) e eu tentei com uma sobressalente.
Tentei dar mais potência com uma fonte de alimentação externa para o HDD USB sem nenhuma alteração, mas como tive o mesmo problema com uma unidade flash USB, não espero um problema de alimentação ou?
Tentei transferir arquivos com thunar, pcmanfm, scp ou rsync. O rsync é o único funcionando, mas com uma forte flutuação da taxa de transferência (de 0 a 20Mo / s). scp me diz que o arquivo está "travado" e interrompe qualquer progresso.
Se eu iniciar o mesmo cartão SD com um RPi 3B (não plus), a transferência de arquivos está funcionando perfeitamente (eu usei por quase 3 anos assim).
Segui dicas deste link sem sucesso, não tendo problemas durante as sessões de ssh ou com vnc.
Alguma ideia ?
toto8551
Todos 204 comentários
Tendo os mesmos problemas estranhos com Pi3B + [1] [2]
IMO, está relacionado ao driver de rede (lan78xx) ou o driver do host usb não lida com as transferências USB corretamente.
Depois de mudar de eth para wlan, está tudo ok
[1] Nunca foi capaz de fazer um backup de imagem de 3 GB (root fs está em um disco USB externo) na rede (kernel 4.9, 4.14 e 4.15 testado). A mesma configuração funciona em um Pi3B mais antigo sem problemas
[2] Quando o root fs está no alvo iSCSI, obtém OOPS massivo do kernel ao usar o kernel 4.14.27+. Depois de mudar para 4.9.87+, a conexão ethernet estava melhor (sem kernel OOPS), mas talvez ainda não estável (mais testes necessários). Kernel 4.15.10+ não testado
mkreisl
em 18 mar. 2018
Eu fiz outro teste.
Agora estou de volta com o kernel oficial do trecho raspbian: 4.9.80-v7, e está funcionando até agora.
Transferi o 10Go de um HDD USB com uma taxa de 20 Mo / s.
toto8551
em 19 mar. 2018
Estou com o mesmo problema aqui ... A tentativa de transferir arquivos grandes pela Ethernet falha depois de um minuto ou mais ... Tudo bem em Wifi ... No entanto, quando tento fazer o downgrade para 4.9.80-v7, recebo quatro piscando luzes verdes no PI3B + ... Posso tirar o cartão e conectá-lo a um Pi2 e ele inicializa muito bem ... Eu então tenho que atualizar o firmware e trocar tudo de volta para o Pi3B + ... Frustrante ...
pjgpetecodes
em 20 mar. 2018
Este bug está relacionado a # 2446? Em caso afirmativo, o próximo kernel 4.14.28 deve corrigi-lo. Reverter para um kernel antigo pode ser uma solução temporária, mas apenas para usuários avançados.
Outras distros são afetadas: xbian, osmc, LibreELEC?
Pelo menos sabemos que a OSMC usava unidades de pré-produção , então podem ser incluídas uma correção / solução alternativa para este problema.
Tenho 10 dias para decidir devolver o RPi 3B +, então quero começar com uma Ethernet funcionando ou apenas devolver a unidade fechada.
fieryo
em 21 mar. 2018
Este bug está relacionado a # 2446? Em caso afirmativo, o próximo kernel 4.14.28 deve corrigi-lo. Reverter para um kernel antigo pode ser uma solução temporária, mas apenas para usuários avançados.
IMO, há uma boa chance de resolver alguns problemas estranhos.
Como já relatado, estou lutando com meu Pi3B + desde que consegui essa peça. O Raspbian parece funcionar no meu cenário de teste [1], mas o XBian sempre travava, mais cedo ou mais tarde. A principal diferença entre Raspbian e XBian é que Rasbian está usando ipv6, enquanto XBian está usando ipv4 (ipv6 é desabilitado por padrão), e esses patches corrigem a pilha ipv4. Depois de habilitar tcp6 no XBian, meu teste parece terminar com sucesso.
[1] Root fs em disco usb (60 GB), montando compartilhamento Samba em meu servidor para / mnt e, em seguida, execute dd if = / dev / sda de = / mnt / test.img bs = 1M status = processo. O Raspbian teve sucesso, o XBian travou sempre de maneiras diferentes: kernel oops, kernel panic ou simplesmente congelou.
mkreisl
em 21 mar. 2018
Se você tiver uma máquina de destino Linux, pode tentar executar este one-liner (você precisará alterar as credenciais de login para o destino):
dd if=/dev/zero bs=1M status=progress | ssh user<strong i="6">@target</strong> "cat >/dev/null"
Eu tive que executar durante a noite e está se aproximando de 2 TB transferidos sem problemas. O canal é criptografado, então os 29,4 MB / s (235 MB / s) que ele está alcançando não são ruins.
Se estiver sólido, mude para:
while true; do date 1>&2; sudo dd if=/dev/mmcblk0 bs=1M status=progress; done | ssh user<strong i="11">@target</strong> "cat >/dev/null"
Então:
while true; do date 1>&2; sudo dd if=/dev/sda bs=1M status=progress; done | ssh user<strong i="15">@target</strong> "cat >/dev/null"
pelwell
em 22 mar. 2018
@pelwell
Claro, existem muitas maneiras de executar um teste. Infelizmente, depois que meus testes foram concluídos com sucesso, meu aplicativo real fazendo um backup de imagem iniciado a partir da GUI Kodi ainda mata o Pi3B + completamente [1], de maneiras diferentes (4.14.27+ principalmente lança kernel Oops # 5, kernel construído com netdev patch, Oops se foi, mas agora ainda está ficando VFS CIFS travado por mais de 15s de mensagem, e Kernel 4.14.29+ compilado hoje à noite não fez nenhuma diferença).
Conclusão:
No momento, o Pi3B + está absolutamente inutilizável, o Pi mais ruim de todos os tempos.
[1] Esse backup está usando btrfs send / receive, envia todos os subvolumes btrfs locais (localizados em um disco USB externo) para uma imagem montada em um compartilhamento de rede (cifs de nfs).
mkreisl
em 22 mar. 2018
No momento, o Pi3B + está absolutamente inutilizável, o Pi mais ruim de todos os tempos. Extremamente frustrante
Para você, aparentemente, mas não para mim - é por isso que estou tentando ser metódico e descobrir qual etapa está causando o problema.
pelwell
em 22 mar. 2018
@mkreisl Por curiosidade, você poderia tentar usar sshfs em vez de CIFS ou NFS? É um módulo FUSE em vez de um driver de sistema de arquivos nativo e usa um protocolo completamente diferente (e muito mais eficiente) durante a transmissão, por isso pode funcionar mesmo que o CIFS e o NFS não o sejam. sudo apt-get install sshfs deve pegá-lo para você (tenho cerca de 99% de certeza de que o Raspbian o tem). Se funcionar, deve pelo menos fornecer algo que você possa usar em curto prazo até que isso seja descoberto.
Ferroin
em 22 mar. 2018
Para você, aparentemente, mas não para mim - é por isso que estou tentando ser metódico e descobrir qual etapa está causando o problema.
Esses testes básicos que você está executando causam o problema. Muitos dados da OMI entrando e saindo do USB estão causando o problema. Essa é a principal diferença entre Pi3B nd Pi3B +, Pi3B tem um hub USB e Pi3B + tem dois:
Pi3B:
Bus 001 Device 004: ID 046d:c503 Logitech, Inc. Cordless Mouse+Keyboard Receiver
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Pi3B +:
Bus 001 Device 004: ID 046d:c503 Logitech, Inc. Cordless Mouse+Keyboard Receiver
Bus 001 Device 005: ID 0424:7800 Standard Microsystems Corp.
Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
@Ferroin Boa ideia, vou testar. Demora algum tempo, tem que modificar o script de backup
mkreisl
em 22 mar. 2018
@Ferroin sshfs não faz diferença, Pi3B + morrendo com kernel Oops novamente (Pi3B funciona perfeitamente)
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.453472] Unable to handle kernel NULL pointer dereference at virtual address 0000000d
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.453480] pgd = a12d8000
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.453484] [0000000d] *pgd=00000000
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.453493] Internal error: Oops: 5 [#1] SMP ARM
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.453578] Modules linked in: dm_mod dax fuse loop hci_uart bluetooth ecdh_generic sg uio_pdrv_genirq uio lirc_rpi(C) lirc_dev fixed frandom ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip_tables x_tables ipv6 snd_bcm2835(C) snd_pcm snd_timer snd brcmfmac cfg80211 rfkill brcmutil evdev rpcsec_gss_krb5 tun uinput
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.454081] CPU: 1 PID: 10626 Comm: sudo Tainted: G C 4.14.29+ #1
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.454170] Hardware name: BCM2835
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.454216] task: 91ab1e00 task.stack: 93ea0000
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.454287] PC is at locks_remove_posix+0x30/0x14c
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.454364] LR is at filp_close+0x68/0x8c
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.454447] pc : [<802e08b0>] lr : [<80286ac4>] psr: 20000013
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.454550] sp : 93ea1eb0 ip : 93ea1f58 fp : 93ea1f54
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.454616] r10: 00000000 r9 : 93ea0000 r8 : 80108204
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.454680] r7 : 00000006 r6 : acc63900 r5 : 9d640180 r4 : ae690440
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.454754] r3 : 00000001 r2 : ad1bb940 r1 : acc63900 r0 : 9d640180
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.454831] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.454914] Control: 10c5383d Table: 212d806a DAC: 00000055
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.454983] Process sudo (pid: 10626, stack limit = 0x93ea0210)
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.455058] Stack: (0x93ea1eb0 to 0x93ea2000)
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.455112] 1ea0: 802fe824 91ab1e00 00000044 802a8f5c
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.455210] 1ec0: 00000004 00000000 00000000 00000100 81f22e80 80d093bc 00000017 808ac294
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.455316] 1ee0: 76ebfe2c 93ea1fb0 7ed36760 808a8780 93ea1f14 93ea1f00 808a8780 806fbae8
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.455440] 1f00: add51c00 add51d74 93ea1f34 93ea1f18 806fbae8 808a7758 add52400 7f0220bc
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.455561] 1f20: add52400 add52444 93ea1f54 00000000 9d640180 acc63900 00000006 80108204
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.455679] 1f40: 93ea0000 00000000 93ea1f74 93ea1f58 80286ac4 802e088c 0000003c acc63900
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.455787] 1f60: 9d640180 00000006 93ea1f94 93ea1f78 802aad38 80286a68 76fbd218 0000000b
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.455892] 1f80: 00000000 00000006 93ea1fa4 93ea1f98 80286b18 802aac7c 00000000 93ea1fa8
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.455993] 1fa0: 80108060 80286af4 76fbd218 0000000b 0000003c 7ed36760 76fbcb5c 76fbcb5c
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.456102] 1fc0: 76fbd218 0000000b 00000000 00000006 01d185b8 7ed36760 76fface8 0000003c
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.456205] 1fe0: 7ed36738 7ed36728 76fbcb6c 76e94fc2 60000030 0000003c 00000000 00000000
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.456325] [<802e08b0>] (locks_remove_posix) from [<80286ac4>] (filp_close+0x68/0x8c)
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.456435] [<80286ac4>] (filp_close) from [<802aad38>] (__close_fd+0xc8/0xec)
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.456529] [<802aad38>] (__close_fd) from [<80286b18>] (SyS_close+0x30/0x58)
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.456626] [<80286b18>] (SyS_close) from [<80108060>] (ret_fast_syscall+0x0/0x28)
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.456728] Code: e59430e8 f57ff05b e3530000 0a000025 (e5b3200c)
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.456857] ---[ end trace 124dc21b94998788 ]---
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.477670] Unable to handle kernel NULL pointer dereference at virtual address 0000000d
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.477836] pgd = 80004000
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.477896] [0000000d] *pgd=00000000
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.477964] Internal error: Oops: 5 [#2] SMP ARM
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.478032] Modules linked in: dm_mod dax fuse loop hci_uart bluetooth ecdh_generic sg uio_pdrv_genirq uio lirc_rpi(C) lirc_dev fixed frandom ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip_tables x_tables ipv6 snd_bcm2835(C) snd_pcm snd_timer snd brcmfmac cfg80211 rfkill brcmutil evdev rpcsec_gss_krb5 tun uinput
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.478580] CPU: 3 PID: 10620 Comm: sudo Tainted: G D C 4.14.29+ #1
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.478678] Hardware name: BCM2835
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.478725] task: 82818f00 task.stack: 86ea8000
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.478800] PC is at locks_remove_posix+0x30/0x14c
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.478867] LR is at filp_close+0x68/0x8c
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.478933] pc : [<802e08b0>] lr : [<80286ac4>] psr: 20040013
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.479016] sp : 86ea9d08 ip : 86ea9db0 fp : 86ea9dac
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.479084] r10: 0000000b r9 : ad41a980 r8 : 00000004
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.479152] r7 : ade91500 r6 : ade91500 r5 : 9d640180 r4 : ae690440
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.479234] r3 : 00000001 r2 : 9d640180 r1 : ade91500 r0 : 9d640180
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.479316] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.479407] Control: 10c5383d Table: 109d806a DAC: 00000055
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.479486] Process sudo (pid: 10620, stack limit = 0x86ea8210)
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.479561] Stack: (0x86ea9d08 to 0x86eaa000)
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.479621] 9d00: 80d87980 809024bc 2e486000 808a6840 af11ad40 86ea9d48
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.479728] 9d20: 8c3da480 8025bc28 ae811a40 80e15480 60040013 60040013 0000008c 00033c4b
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.479832] 9d40: 00000000 808a8780 86ea9d6c 86ea9d58 808a8780 806fbae8 add51c00 add51d74
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.479956] 9d60: 86ea9d8c 86ea9d70 806fbae8 808a7758 add52400 7f0220bc add52400 add52444
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.480075] 9d80: 86ea9dac 00000000 9d640180 ade91500 ade91500 00000004 ad41a980 0000000b
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.480184] 9da0: 86ea9dcc 86ea9db0 80286ac4 802e088c 00000009 000000f0 00000000 ade91500
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.480287] 9dc0: 86ea9df4 86ea9dd0 802aa864 80286a68 82818f00 82819440 ade91500 ae811a40
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.480389] 9de0: 00000001 ae811a78 86ea9e14 86ea9df8 802aa974 802aa7bc 82818f00 00000000
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.480493] 9e00: 00000544 ae811a40 86ea9e54 86ea9e18 80121d6c 802aa928 86ea9e74 86ea9e28
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.480595] 9e20: 86ea9edc 86ea9fb0 00000000 0000000b ac9a02c0 86ea9edc 86ea8000 00106001
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.480698] 9e40: 86ea8000 0000000b 86ea9e74 86ea9e58 8012260c 801219e0 00000000 ad6aba88
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.480800] 9e60: 86ea9edc 86ea8000 86ea9ec4 86ea9e78 8012d9f4 801225cc 80d02040 418004fc
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.480903] 9e80: 80d03d68 86ea9ec8 ac9a02c0 ad6abec4 ad6ab9c0 000000a0 0000000b 76e27574
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.494505] 9ea0: 86ea9ec8 86ea9fb0 76e27576 00000000 86ea8000 00000000 86ea9f8c 86ea9ec8
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.506477] 9ec0: 8010b318 8012d6c8 86ea9ef4 86ea9ed8 8012d084 8012cf08 00000000 0000000b
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.518136] 9ee0: 00000000 00000000 0000297c 00000000 ad6ab9e8 00000001 82818f00 00000000
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.531395] 9f00: 00000000 0000297c 00000000 ad6ab9e8 00000001 82818f00 00000001 86ea9f68
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.545698] 9f20: 86ea9f64 86ea9f30 8012f17c 801edc50 82819444 00000002 7ed36aa8 00000000
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.558183] 9f40: 00000002 7ed36aa8 000000ae 80108204 86ea8000 00000000 86ea9fa4 86ea9f68
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.570528] 9f60: 8012f6f0 00000001 86ea8010 80108204 86ea9fb0 80108204 86ea8000 00000000
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.582517] 9f80: 86ea9fac 86ea9f90 8010b820 8010b260 7ed36aa8 0000000b 0000000b 00000025
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.594335] 9fa0: 00000000 86ea9fb0 80108094 8010b774 00000000 0000000b 3a4d6900 3a4d6900
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.607730] 9fc0: 7ed36aa8 0000000b 0000000b 00000025 01d15c58 0049016c 00000000 7ed36a18
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.621658] 9fe0: 004a1dd8 7ed369c4 0047dd5b 76e27576 20040030 0000297c a302000d 64690063
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.635304] [<802e08b0>] (locks_remove_posix) from [<80286ac4>] (filp_close+0x68/0x8c)
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.647889] [<80286ac4>] (filp_close) from [<802aa864>] (put_files_struct+0xb4/0x10c)
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.660265] [<802aa864>] (put_files_struct) from [<802aa974>] (exit_files+0x58/0x5c)
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.672651] [<802aa974>] (exit_files) from [<80121d6c>] (do_exit+0x398/0xba0)
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.684677] [<80121d6c>] (do_exit) from [<8012260c>] (do_group_exit+0x4c/0xe4)
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.696657] [<8012260c>] (do_group_exit) from [<8012d9f4>] (get_signal+0x338/0x6e0)
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.708835] [<8012d9f4>] (get_signal) from [<8010b318>] (do_signal+0xc4/0x3e4)
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.720791] [<8010b318>] (do_signal) from [<8010b820>] (do_work_pending+0xb8/0xd0)
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.732744] [<8010b820>] (do_work_pending) from [<80108094>] (slow_work_pending+0xc/0x20)
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.744414] Code: e59430e8 f57ff05b e3530000 0a000025 (e5b3200c)
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.755952] ---[ end trace 124dc21b94998789 ]---
Mar 22 17:40:00 kmxbilr2 kernel: [ 555.772247] Fixing recursive fault but reboot is needed!
Mar 22 17:40:02 kmxbilr2 kernel: [ 557.572209] Unable to handle kernel paging request at virtual address 04bc7ffc
Mar 22 17:40:02 kmxbilr2 kernel: [ 557.583366] pgd = a0380000
Mar 22 17:40:02 kmxbilr2 kernel: [ 557.594624] [04bc7ffc] *pgd=00000000
Mar 22 17:40:02 kmxbilr2 kernel: [ 557.605878] Internal error: Oops: 5 [#3] SMP ARM
Mar 22 17:40:02 kmxbilr2 kernel: [ 557.616992] Modules linked in: dm_mod dax fuse loop hci_uart bluetooth ecdh_generic sg uio_pdrv_genirq uio lirc_rpi(C) lirc_dev fixed frandom ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip_tables x_tables ipv6 snd_bcm2835(C) snd_pcm snd_timer snd brcmfmac cfg80211 rfkill brcmutil evdev rpcsec_gss_krb5 tun uinput
Mar 22 17:40:02 kmxbilr2 kernel: [ 557.639993] CPU: 3 PID: 10496 Comm: btrfs Tainted: G D C 4.14.29+ #1
Mar 22 17:40:02 kmxbilr2 kernel: [ 557.651518] Hardware name: BCM2835
Mar 22 17:40:02 kmxbilr2 kernel: [ 557.662917] task: 9851bc00 task.stack: a01e4000
Mar 22 17:40:02 kmxbilr2 kernel: [ 557.674480] PC is at __d_lookup_rcu+0x68/0x19c
Mar 22 17:40:02 kmxbilr2 kernel: [ 557.685867] LR is at lookup_fast+0x4c/0x2c8
Mar 22 17:40:02 kmxbilr2 kernel: [ 557.697094] pc : [<802a4da0>] lr : [<80295cc4>] psr: 20010013
Mar 22 17:40:02 kmxbilr2 kernel: [ 557.708335] sp : a01e5d20 ip : 80d04590 fp : a01e5d5c
Mar 22 17:40:02 kmxbilr2 kernel: [ 557.719619] r10: a01e5e50 r9 : 00000006 r8 : e6ad3f44
Mar 22 17:40:02 kmxbilr2 kernel: [ 557.730983] r7 : a03d8550 r6 : a03d8550 r5 : 00000000 r4 : 04bc8000
Mar 22 17:40:02 kmxbilr2 kernel: [ 557.741942] r3 : 0001cd5a r2 : 00004000 r1 : 00000000 r0 : a03d8550
Mar 22 17:40:02 kmxbilr2 kernel: [ 557.752961] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Mar 22 17:40:02 kmxbilr2 kernel: [ 557.763554] Control: 10c5383d Table: 2038006a DAC: 00000055
Mar 22 17:40:02 kmxbilr2 kernel: [ 557.774189] Process btrfs (pid: 10496, stack limit = 0xa01e4210)
Mar 22 17:40:02 kmxbilr2 kernel: [ 557.784760] Stack: (0xa01e5d20 to 0xa01e6000)
Mar 22 17:40:02 kmxbilr2 kernel: [ 557.795359] 5d20: 8c6f2000 a01e5d6c 00000006 8c6f0038 a01e5d5c a01e5e48 00000000 a01e5da8
Mar 22 17:40:02 kmxbilr2 kernel: [ 557.806204] 5d40: a03d8550 a01e5da0 ad639b10 a01e5da4 a01e5d9c a01e5d60 80295cc4 802a4d44
Mar 22 17:40:02 kmxbilr2 kernel: [ 557.817041] 5d60: 8c6f2000 ae4085a0 00001455 00000006 00001542 a01e5e48 00000000 00000003
Mar 22 17:40:02 kmxbilr2 kernel: [ 557.828472] 5d80: 8c6f003f a01e5e48 8cff9c59 a03d8550 a01e5dd4 a01e5da0 80298140 80295c84
Mar 22 17:40:02 kmxbilr2 kernel: [ 557.843155] 5da0: a01e5dc4 a01e5db0 8029683c 8042ea20 c2d0f82e 47090a62 e6ad3f44 8c6f003f
Mar 22 17:40:02 kmxbilr2 kernel: [ 557.855354] 5dc0: a01e5e48 8cff9c59 a01e5e24 a01e5dd8 8029856c 80298110 80295448 61c88647
Mar 22 17:40:02 kmxbilr2 kernel: [ 557.866613] 5de0: 00000000 00000006 a01e5e48 8c6f0010 a01e5e24 a01e5e00 80294f74 8c6f0010
Mar 22 17:40:02 kmxbilr2 kernel: [ 557.878046] 5e00: a01e5e48 a01e5f38 a01e5f38 a01e5f40 00000000 ffffff9c a01e5e44 a01e5e28
Mar 22 17:40:02 kmxbilr2 kernel: [ 557.889410] 5e20: 802988c4 802983ec 8c6f0000 a01e5e48 00000000 a01e5f38 a01e5eec a01e5e48
Mar 22 17:40:02 kmxbilr2 kernel: [ 557.900746] 5e40: 8029a4b4 8029889c ad639b10 a03d8550 e6ad3f44 00000006 8c6f0038 80276ee4
Mar 22 17:40:02 kmxbilr2 kernel: [ 557.912237] 5e60: ae990c10 ae7af660 883d6660 00000050 00000006 000003a4 00000000 00000000
Mar 22 17:40:02 kmxbilr2 kernel: [ 557.923647] 5e80: 00000000 a01e5e88 80d0459c 8c6f0000 80d0459c 7ea7a81c 00000000 00000000
Mar 22 17:40:02 kmxbilr2 kernel: [ 557.934994] 5ea0: a01e5edc a01e5eb0 8029a30c 805d1904 a01e5e88 8c6f4000 8c6f0000 00000000
Mar 22 17:40:02 kmxbilr2 kernel: [ 557.946359] 5ec0: 00000026 00000002 ffffff9c ffffff9c 8c6f4000 7ea7981c a01e5f50 00000026
Mar 22 17:40:02 kmxbilr2 kernel: [ 557.957715] 5ee0: a01e5f8c a01e5ef0 8029b984 8029a444 a01e5f50 a01e5f28 98785c08 a01e5ef0
Mar 22 17:40:02 kmxbilr2 kernel: [ 557.969150] 5f00: 00000001 802ad51c 98785c00 00000800 00000000 00000000 7ea7a81c ffffff9c
Mar 22 17:40:02 kmxbilr2 kernel: [ 557.980558] 5f20: 00000000 00000000 98785c08 00000000 ad639b10 962fd330 a01e4000 00000000
Mar 22 17:40:02 kmxbilr2 kernel: [ 557.992053] 5f40: aa64a66c 0000000a 8c6f402a 80276ee4 00000000 00000000 a01e5f7c 98785c00
Mar 22 17:40:02 kmxbilr2 kernel: [ 558.003698] 5f60: 98785c00 00000000 00e9a010 00e9a050 00000026 80108204 a01e4000 00000000
Mar 22 17:40:02 kmxbilr2 kernel: [ 558.015188] 5f80: a01e5fa4 a01e5f90 8029bd9c 8029b8bc 00000000 00e9a050 00000000 a01e5fa8
Mar 22 17:40:02 kmxbilr2 kernel: [ 558.026723] 5fa0: 80108060 8029bd74 00000000 00e9a010 7ea7981c 7ea7a81c ffffffff 00000000
Mar 22 17:40:02 kmxbilr2 kernel: [ 558.038198] 5fc0: 00000000 00e9a010 00e9a050 00000026 004fd000 76f05ce8 7ea7981c 7ea7a81c
Mar 22 17:40:02 kmxbilr2 kernel: [ 558.049811] 5fe0: 004fd198 7ea79814 0049cc9b 76cd7796 00010030 7ea7981c 00000000 00000000
Mar 22 17:40:02 kmxbilr2 kernel: [ 558.061386] [<802a4da0>] (__d_lookup_rcu) from [<80295cc4>] (lookup_fast+0x4c/0x2c8)
Mar 22 17:40:02 kmxbilr2 kernel: [ 558.072944] [<80295cc4>] (lookup_fast) from [<80298140>] (walk_component+0x3c/0x2dc)
Mar 22 17:40:02 kmxbilr2 kernel: [ 558.084330] [<80298140>] (walk_component) from [<8029856c>] (link_path_walk+0x18c/0x4b0)
Mar 22 17:40:02 kmxbilr2 kernel: [ 558.095582] [<8029856c>] (link_path_walk) from [<802988c4>] (path_parentat+0x34/0x6c)
Mar 22 17:40:02 kmxbilr2 kernel: [ 558.106851] [<802988c4>] (path_parentat) from [<8029a4b4>] (filename_parentat+0x7c/0x104)
Mar 22 17:40:02 kmxbilr2 kernel: [ 558.117923] [<8029a4b4>] (filename_parentat) from [<8029b984>] (SyS_renameat2+0xd4/0x48c)
Mar 22 17:40:02 kmxbilr2 kernel: [ 558.129156] [<8029b984>] (SyS_renameat2) from [<8029bd9c>] (SyS_rename+0x34/0x3c)
Mar 22 17:40:02 kmxbilr2 kernel: [ 558.140092] [<8029bd9c>] (SyS_rename) from [<80108060>] (ret_fast_syscall+0x0/0x28)
Mar 22 17:40:02 kmxbilr2 kernel: [ 558.150966] Code: ea000002 e5944000 e3540000 0a000028 (e5141004)
Mar 22 17:40:02 kmxbilr2 kernel: [ 558.161756] ---[ end trace 124dc21b9499878a ]---
Mar 22 17:40:05 kmxbilr2 kernel: [ 560.624738] Alignment trap: not handling instruction e1b04f9f at [<80566d48>]
Mar 22 17:40:05 kmxbilr2 kernel: [ 560.635458] Unhandled fault: alignment exception (0x001) at 0x9ac47754
Mar 22 17:40:05 kmxbilr2 kernel: [ 560.646194] pgd = acecc000
Mar 22 17:40:05 kmxbilr2 kernel: [ 560.656802] [9ac47754] *pgd=1ac1141e(bad)
Mar 22 17:40:05 kmxbilr2 kernel: [ 560.667391] Internal error: : 1 [#4] SMP ARM
Mar 22 17:40:05 kmxbilr2 kernel: [ 560.677894] Modules linked in: dm_mod dax fuse loop hci_uart bluetooth ecdh_generic sg uio_pdrv_genirq uio lirc_rpi(C) lirc_dev fixed frandom ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip_tables x_tables ipv6 snd_bcm2835(C) snd_pcm snd_timer snd brcmfmac cfg80211 rfkill brcmutil evdev rpcsec_gss_krb5 tun uinput
Mar 22 17:40:05 kmxbilr2 kernel: [ 560.700191] CPU: 3 PID: 4194 Comm: PeripBusUSBUdev Tainted: G D C 4.14.29+ #1
Mar 22 17:40:05 kmxbilr2 kernel: [ 560.711520] Hardware name: BCM2835
Mar 22 17:40:05 kmxbilr2 kernel: [ 560.724080] task: 81945a00 task.stack: 9e712000
Mar 22 17:40:05 kmxbilr2 kernel: [ 560.737866] PC is at lockref_put_return+0x3c/0x94
Mar 22 17:40:05 kmxbilr2 kernel: [ 560.750567] LR is at dput+0x40/0x2d0
Mar 22 17:40:05 kmxbilr2 kernel: [ 560.761780] pc : [<80566d4c>] lr : [<802a1abc>] psr: 20060013
Mar 22 17:40:05 kmxbilr2 kernel: [ 560.773122] sp : 9e713de0 ip : 9e713e00 fp : 9e713dfc
Mar 22 17:40:05 kmxbilr2 kernel: [ 560.784351] r10: 00000000 r9 : 9e712000 r8 : 9e713f60
Mar 22 17:40:05 kmxbilr2 kernel: [ 560.795460] r7 : 00000001 r6 : 00010001 r5 : 00000001 r4 : 00010001
Mar 22 17:40:05 kmxbilr2 kernel: [ 560.806753] r3 : 00000000 r2 : 00010001 r1 : 00000000 r0 : 9ac47754
Mar 22 17:40:05 kmxbilr2 kernel: [ 560.817978] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Mar 22 17:40:05 kmxbilr2 kernel: [ 560.829007] Control: 10c5383d Table: 2cecc06a DAC: 00000055
Mar 22 17:40:05 kmxbilr2 kernel: [ 560.839867] Process PeripBusUSBUdev (pid: 4194, stack limit = 0x9e712210)
Mar 22 17:40:05 kmxbilr2 kernel: [ 560.851294] Stack: (0x9e713de0 to 0x9e714000)
Mar 22 17:40:05 kmxbilr2 kernel: [ 560.863891] 3de0: 9ac47704 00080040 9ac47754 00000041 9e713e24 9e713e00 802a1abc 80566d1c
Mar 22 17:40:05 kmxbilr2 kernel: [ 560.876801] 3e00: 00000000 9e713e78 9e713f60 00000041 9e713f60 9e712000 9e713e44 9e713e28
Mar 22 17:40:05 kmxbilr2 kernel: [ 560.887838] 3e20: 80294b9c 802a1a88 9e713e78 fffffffe 9e713f60 00000041 9e713e74 9e713e48
Mar 22 17:40:05 kmxbilr2 kernel: [ 560.900010] 3e40: 802989bc 80294b5c 9e6683f8 af57c6bc 00000000 00000000 00000001 8c6f5000
Mar 22 17:40:05 kmxbilr2 kernel: [ 560.915033] 3e60: 9e713e78 00000001 9e713f24 9e713e78 8029a5d8 80298908 ae990310 9ac47704
Mar 22 17:40:05 kmxbilr2 kernel: [ 560.929842] 3e80: e73d77c1 00000006 8c6f5025 00000000 ae990c10 ae7af660 ae7db2b0 00000001
Mar 22 17:40:05 kmxbilr2 kernel: [ 560.942629] 3ea0: 9e713dd0 000003be 00000000 00000000 00000000 9e713eb8 00000000 00000000
Mar 22 17:40:05 kmxbilr2 kernel: [ 560.955273] 3ec0: 00001000 8c6f6000 00000000 00000001 80d0459c 8c6f5000 80d0459c 6b2fea18
Mar 22 17:40:05 kmxbilr2 kernel: [ 560.966619] 3ee0: 00000000 00000001 8c6f5000 00000000 8029a30c 00000002 ffffff9c 00000001
Mar 22 17:40:05 kmxbilr2 kernel: [ 560.978523] 3f00: ffffff9c 00000001 ffffff9c 9e713f60 ffffff9c 6b2fea18 9e713f4c 9e713f28
Mar 22 17:40:05 kmxbilr2 kernel: [ 560.992103] 3f20: 8029a720 8029a548 00000000 00000000 9e713f4c 00000001 00000000 acb3e980
Mar 22 17:40:05 kmxbilr2 kernel: [ 561.005850] 3f40: 9e713f94 9e713f50 80287344 8029a6d8 00000000 00000000 aaa67500 00000000
Mar 22 17:40:05 kmxbilr2 kernel: [ 561.017377] 3f60: 00000000 00000000 00000005 00000000 5c21ee28 76f78ce8 00000021 80108204
Mar 22 17:40:05 kmxbilr2 kernel: [ 561.029029] 3f80: 9e712000 00000000 9e713fa4 9e713f98 802874c4 802872b4 00000000 9e713fa8
Mar 22 17:40:05 kmxbilr2 kernel: [ 561.040579] 3fa0: 80108060 802874ac 00000000 5c21ee28 6b2fea18 00000000 00000000 6b2fea33
Mar 22 17:40:05 kmxbilr2 kernel: [ 561.052969] 3fc0: 00000000 5c21ee28 76f78ce8 00000021 6b2fea18 6b2fea48 716d7b30 ffffffea
Mar 22 17:40:05 kmxbilr2 kernel: [ 561.068944] 3fe0: 75eebf10 6b2fea04 75ee4b7b 759c1b66 20060030 6b2fea18 aa98abba faaaaaea
Mar 22 17:40:05 kmxbilr2 kernel: [ 561.083256] [<80566d4c>] (lockref_put_return) from [<802a1abc>] (dput+0x40/0x2d0)
Mar 22 17:40:05 kmxbilr2 kernel: [ 561.094752] [<802a1abc>] (dput) from [<80294b9c>] (terminate_walk+0x4c/0xc0)
Mar 22 17:40:05 kmxbilr2 kernel: [ 561.106786] [<80294b9c>] (terminate_walk) from [<802989bc>] (path_lookupat+0xc0/0x204)
Mar 22 17:40:05 kmxbilr2 kernel: [ 561.120543] [<802989bc>] (path_lookupat) from [<8029a5d8>] (filename_lookup+0x9c/0xf8)
Mar 22 17:40:05 kmxbilr2 kernel: [ 561.133721] [<8029a5d8>] (filename_lookup) from [<8029a720>] (user_path_at_empty+0x54/0x5c)
Mar 22 17:40:05 kmxbilr2 kernel: [ 561.144836] [<8029a720>] (user_path_at_empty) from [<80287344>] (SyS_faccessat+0x9c/0x1f8)
Mar 22 17:40:05 kmxbilr2 kernel: [ 561.155787] [<80287344>] (SyS_faccessat) from [<802874c4>] (SyS_access+0x24/0x28)
Mar 22 17:40:05 kmxbilr2 kernel: [ 561.166755] [<802874c4>] (SyS_access) from [<80108060>] (ret_fast_syscall+0x0/0x28)
Mar 22 17:40:05 kmxbilr2 kernel: [ 561.177608] Code: e1a07005 da000015 f590f000 e1b04f9f (e1340006)
Mar 22 17:40:05 kmxbilr2 kernel: [ 561.188475] ---[ end trace 124dc21b9499878b ]---
... e relatórios dmesg
[ 555.453472] Unable to handle kernel NULL pointer dereference at virtual address 0000000d
[ 555.453480] pgd = a12d8000
[ 555.453484] [0000000d] *pgd=00000000
[ 555.453493] Internal error: Oops: 5 [#1] SMP ARM
[ 555.453578] Modules linked in: dm_mod dax fuse loop hci_uart bluetooth ecdh_generic sg uio_pdrv_genirq uio lirc_rpi(C) lirc_dev fixed frandom ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip_tables x_tables ipv6 snd_bcm2835(C) snd_pcm snd_timer snd brcmfmac cfg80211 rfkill brcmutil evdev rpcsec_gss_krb5 tun uinput
[ 555.454081] CPU: 1 PID: 10626 Comm: sudo Tainted: G C 4.14.29+ #1
[ 555.454170] Hardware name: BCM2835
[ 555.454216] task: 91ab1e00 task.stack: 93ea0000
[ 555.454287] PC is at locks_remove_posix+0x30/0x14c
[ 555.454364] LR is at filp_close+0x68/0x8c
[ 555.454447] pc : [<802e08b0>] lr : [<80286ac4>] psr: 20000013
[ 555.454550] sp : 93ea1eb0 ip : 93ea1f58 fp : 93ea1f54
[ 555.454616] r10: 00000000 r9 : 93ea0000 r8 : 80108204
[ 555.454680] r7 : 00000006 r6 : acc63900 r5 : 9d640180 r4 : ae690440
[ 555.454754] r3 : 00000001 r2 : ad1bb940 r1 : acc63900 r0 : 9d640180
[ 555.454831] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 555.454914] Control: 10c5383d Table: 212d806a DAC: 00000055
[ 555.454983] Process sudo (pid: 10626, stack limit = 0x93ea0210)
[ 555.455058] Stack: (0x93ea1eb0 to 0x93ea2000)
[ 555.455112] 1ea0: 802fe824 91ab1e00 00000044 802a8f5c
[ 555.455210] 1ec0: 00000004 00000000 00000000 00000100 81f22e80 80d093bc 00000017 808ac294
[ 555.455316] 1ee0: 76ebfe2c 93ea1fb0 7ed36760 808a8780 93ea1f14 93ea1f00 808a8780 806fbae8
[ 555.455440] 1f00: add51c00 add51d74 93ea1f34 93ea1f18 806fbae8 808a7758 add52400 7f0220bc
[ 555.455561] 1f20: add52400 add52444 93ea1f54 00000000 9d640180 acc63900 00000006 80108204
[ 555.455679] 1f40: 93ea0000 00000000 93ea1f74 93ea1f58 80286ac4 802e088c 0000003c acc63900
[ 555.455787] 1f60: 9d640180 00000006 93ea1f94 93ea1f78 802aad38 80286a68 76fbd218 0000000b
[ 555.455892] 1f80: 00000000 00000006 93ea1fa4 93ea1f98 80286b18 802aac7c 00000000 93ea1fa8
[ 555.455993] 1fa0: 80108060 80286af4 76fbd218 0000000b 0000003c 7ed36760 76fbcb5c 76fbcb5c
[ 555.456102] 1fc0: 76fbd218 0000000b 00000000 00000006 01d185b8 7ed36760 76fface8 0000003c
[ 555.456205] 1fe0: 7ed36738 7ed36728 76fbcb6c 76e94fc2 60000030 0000003c 00000000 00000000
[ 555.456325] [<802e08b0>] (locks_remove_posix) from [<80286ac4>] (filp_close+0x68/0x8c)
[ 555.456435] [<80286ac4>] (filp_close) from [<802aad38>] (__close_fd+0xc8/0xec)
[ 555.456529] [<802aad38>] (__close_fd) from [<80286b18>] (SyS_close+0x30/0x58)
[ 555.456626] [<80286b18>] (SyS_close) from [<80108060>] (ret_fast_syscall+0x0/0x28)
[ 555.456728] Code: e59430e8 f57ff05b e3530000 0a000025 (e5b3200c)
[ 555.456857] ---[ end trace 124dc21b94998788 ]---
[ 555.477670] Unable to handle kernel NULL pointer dereference at virtual address 0000000d
[ 555.477836] pgd = 80004000
[ 555.477896] [0000000d] *pgd=00000000
[ 555.477964] Internal error: Oops: 5 [#2] SMP ARM
[ 555.478032] Modules linked in: dm_mod dax fuse loop hci_uart bluetooth ecdh_generic sg uio_pdrv_genirq uio lirc_rpi(C) lirc_dev fixed frandom ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip_tables x_tables ipv6 snd_bcm2835(C) snd_pcm snd_timer snd brcmfmac cfg80211 rfkill brcmutil evdev rpcsec_gss_krb5 tun uinput
[ 555.478580] CPU: 3 PID: 10620 Comm: sudo Tainted: G D C 4.14.29+ #1
[ 555.478678] Hardware name: BCM2835
[ 555.478725] task: 82818f00 task.stack: 86ea8000
[ 555.478800] PC is at locks_remove_posix+0x30/0x14c
[ 555.478867] LR is at filp_close+0x68/0x8c
[ 555.478933] pc : [<802e08b0>] lr : [<80286ac4>] psr: 20040013
[ 555.479016] sp : 86ea9d08 ip : 86ea9db0 fp : 86ea9dac
[ 555.479084] r10: 0000000b r9 : ad41a980 r8 : 00000004
[ 555.479152] r7 : ade91500 r6 : ade91500 r5 : 9d640180 r4 : ae690440
[ 555.479234] r3 : 00000001 r2 : 9d640180 r1 : ade91500 r0 : 9d640180
[ 555.479316] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 555.479407] Control: 10c5383d Table: 109d806a DAC: 00000055
[ 555.479486] Process sudo (pid: 10620, stack limit = 0x86ea8210)
[ 555.479561] Stack: (0x86ea9d08 to 0x86eaa000)
[ 555.479621] 9d00: 80d87980 809024bc 2e486000 808a6840 af11ad40 86ea9d48
[ 555.479728] 9d20: 8c3da480 8025bc28 ae811a40 80e15480 60040013 60040013 0000008c 00033c4b
[ 555.479832] 9d40: 00000000 808a8780 86ea9d6c 86ea9d58 808a8780 806fbae8 add51c00 add51d74
[ 555.479956] 9d60: 86ea9d8c 86ea9d70 806fbae8 808a7758 add52400 7f0220bc add52400 add52444
[ 555.480075] 9d80: 86ea9dac 00000000 9d640180 ade91500 ade91500 00000004 ad41a980 0000000b
[ 555.480184] 9da0: 86ea9dcc 86ea9db0 80286ac4 802e088c 00000009 000000f0 00000000 ade91500
[ 555.480287] 9dc0: 86ea9df4 86ea9dd0 802aa864 80286a68 82818f00 82819440 ade91500 ae811a40
[ 555.480389] 9de0: 00000001 ae811a78 86ea9e14 86ea9df8 802aa974 802aa7bc 82818f00 00000000
[ 555.480493] 9e00: 00000544 ae811a40 86ea9e54 86ea9e18 80121d6c 802aa928 86ea9e74 86ea9e28
[ 555.480595] 9e20: 86ea9edc 86ea9fb0 00000000 0000000b ac9a02c0 86ea9edc 86ea8000 00106001
[ 555.480698] 9e40: 86ea8000 0000000b 86ea9e74 86ea9e58 8012260c 801219e0 00000000 ad6aba88
[ 555.480800] 9e60: 86ea9edc 86ea8000 86ea9ec4 86ea9e78 8012d9f4 801225cc 80d02040 418004fc
[ 555.480903] 9e80: 80d03d68 86ea9ec8 ac9a02c0 ad6abec4 ad6ab9c0 000000a0 0000000b 76e27574
[ 555.494505] 9ea0: 86ea9ec8 86ea9fb0 76e27576 00000000 86ea8000 00000000 86ea9f8c 86ea9ec8
[ 555.506477] 9ec0: 8010b318 8012d6c8 86ea9ef4 86ea9ed8 8012d084 8012cf08 00000000 0000000b
[ 555.518136] 9ee0: 00000000 00000000 0000297c 00000000 ad6ab9e8 00000001 82818f00 00000000
[ 555.531395] 9f00: 00000000 0000297c 00000000 ad6ab9e8 00000001 82818f00 00000001 86ea9f68
[ 555.545698] 9f20: 86ea9f64 86ea9f30 8012f17c 801edc50 82819444 00000002 7ed36aa8 00000000
[ 555.558183] 9f40: 00000002 7ed36aa8 000000ae 80108204 86ea8000 00000000 86ea9fa4 86ea9f68
[ 555.570528] 9f60: 8012f6f0 00000001 86ea8010 80108204 86ea9fb0 80108204 86ea8000 00000000
[ 555.582517] 9f80: 86ea9fac 86ea9f90 8010b820 8010b260 7ed36aa8 0000000b 0000000b 00000025
[ 555.594335] 9fa0: 00000000 86ea9fb0 80108094 8010b774 00000000 0000000b 3a4d6900 3a4d6900
[ 555.607730] 9fc0: 7ed36aa8 0000000b 0000000b 00000025 01d15c58 0049016c 00000000 7ed36a18
[ 555.621658] 9fe0: 004a1dd8 7ed369c4 0047dd5b 76e27576 20040030 0000297c a302000d 64690063
[ 555.635304] [<802e08b0>] (locks_remove_posix) from [<80286ac4>] (filp_close+0x68/0x8c)
[ 555.647889] [<80286ac4>] (filp_close) from [<802aa864>] (put_files_struct+0xb4/0x10c)
[ 555.660265] [<802aa864>] (put_files_struct) from [<802aa974>] (exit_files+0x58/0x5c)
[ 555.672651] [<802aa974>] (exit_files) from [<80121d6c>] (do_exit+0x398/0xba0)
[ 555.684677] [<80121d6c>] (do_exit) from [<8012260c>] (do_group_exit+0x4c/0xe4)
[ 555.696657] [<8012260c>] (do_group_exit) from [<8012d9f4>] (get_signal+0x338/0x6e0)
[ 555.708835] [<8012d9f4>] (get_signal) from [<8010b318>] (do_signal+0xc4/0x3e4)
[ 555.720791] [<8010b318>] (do_signal) from [<8010b820>] (do_work_pending+0xb8/0xd0)
[ 555.732744] [<8010b820>] (do_work_pending) from [<80108094>] (slow_work_pending+0xc/0x20)
[ 555.744414] Code: e59430e8 f57ff05b e3530000 0a000025 (e5b3200c)
[ 555.755952] ---[ end trace 124dc21b94998789 ]---
[ 555.772247] Fixing recursive fault but reboot is needed!
[ 557.572209] Unable to handle kernel paging request at virtual address 04bc7ffc
[ 557.583366] pgd = a0380000
[ 557.594624] [04bc7ffc] *pgd=00000000
[ 557.605878] Internal error: Oops: 5 [#3] SMP ARM
[ 557.616992] Modules linked in: dm_mod dax fuse loop hci_uart bluetooth ecdh_generic sg uio_pdrv_genirq uio lirc_rpi(C) lirc_dev fixed frandom ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip_tables x_tables ipv6 snd_bcm2835(C) snd_pcm snd_timer snd brcmfmac cfg80211 rfkill brcmutil evdev rpcsec_gss_krb5 tun uinput
[ 557.639993] CPU: 3 PID: 10496 Comm: btrfs Tainted: G D C 4.14.29+ #1
[ 557.651518] Hardware name: BCM2835
[ 557.662917] task: 9851bc00 task.stack: a01e4000
[ 557.674480] PC is at __d_lookup_rcu+0x68/0x19c
[ 557.685867] LR is at lookup_fast+0x4c/0x2c8
[ 557.697094] pc : [<802a4da0>] lr : [<80295cc4>] psr: 20010013
[ 557.708335] sp : a01e5d20 ip : 80d04590 fp : a01e5d5c
[ 557.719619] r10: a01e5e50 r9 : 00000006 r8 : e6ad3f44
[ 557.730983] r7 : a03d8550 r6 : a03d8550 r5 : 00000000 r4 : 04bc8000
[ 557.741942] r3 : 0001cd5a r2 : 00004000 r1 : 00000000 r0 : a03d8550
[ 557.752961] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 557.763554] Control: 10c5383d Table: 2038006a DAC: 00000055
[ 557.774189] Process btrfs (pid: 10496, stack limit = 0xa01e4210)
[ 557.784760] Stack: (0xa01e5d20 to 0xa01e6000)
[ 557.795359] 5d20: 8c6f2000 a01e5d6c 00000006 8c6f0038 a01e5d5c a01e5e48 00000000 a01e5da8
[ 557.806204] 5d40: a03d8550 a01e5da0 ad639b10 a01e5da4 a01e5d9c a01e5d60 80295cc4 802a4d44
[ 557.817041] 5d60: 8c6f2000 ae4085a0 00001455 00000006 00001542 a01e5e48 00000000 00000003
[ 557.828472] 5d80: 8c6f003f a01e5e48 8cff9c59 a03d8550 a01e5dd4 a01e5da0 80298140 80295c84
[ 557.843155] 5da0: a01e5dc4 a01e5db0 8029683c 8042ea20 c2d0f82e 47090a62 e6ad3f44 8c6f003f
[ 557.855354] 5dc0: a01e5e48 8cff9c59 a01e5e24 a01e5dd8 8029856c 80298110 80295448 61c88647
[ 557.866613] 5de0: 00000000 00000006 a01e5e48 8c6f0010 a01e5e24 a01e5e00 80294f74 8c6f0010
[ 557.878046] 5e00: a01e5e48 a01e5f38 a01e5f38 a01e5f40 00000000 ffffff9c a01e5e44 a01e5e28
[ 557.889410] 5e20: 802988c4 802983ec 8c6f0000 a01e5e48 00000000 a01e5f38 a01e5eec a01e5e48
[ 557.900746] 5e40: 8029a4b4 8029889c ad639b10 a03d8550 e6ad3f44 00000006 8c6f0038 80276ee4
[ 557.912237] 5e60: ae990c10 ae7af660 883d6660 00000050 00000006 000003a4 00000000 00000000
[ 557.923647] 5e80: 00000000 a01e5e88 80d0459c 8c6f0000 80d0459c 7ea7a81c 00000000 00000000
[ 557.934994] 5ea0: a01e5edc a01e5eb0 8029a30c 805d1904 a01e5e88 8c6f4000 8c6f0000 00000000
[ 557.946359] 5ec0: 00000026 00000002 ffffff9c ffffff9c 8c6f4000 7ea7981c a01e5f50 00000026
[ 557.957715] 5ee0: a01e5f8c a01e5ef0 8029b984 8029a444 a01e5f50 a01e5f28 98785c08 a01e5ef0
[ 557.969150] 5f00: 00000001 802ad51c 98785c00 00000800 00000000 00000000 7ea7a81c ffffff9c
[ 557.980558] 5f20: 00000000 00000000 98785c08 00000000 ad639b10 962fd330 a01e4000 00000000
[ 557.992053] 5f40: aa64a66c 0000000a 8c6f402a 80276ee4 00000000 00000000 a01e5f7c 98785c00
[ 558.003698] 5f60: 98785c00 00000000 00e9a010 00e9a050 00000026 80108204 a01e4000 00000000
[ 558.015188] 5f80: a01e5fa4 a01e5f90 8029bd9c 8029b8bc 00000000 00e9a050 00000000 a01e5fa8
[ 558.026723] 5fa0: 80108060 8029bd74 00000000 00e9a010 7ea7981c 7ea7a81c ffffffff 00000000
[ 558.038198] 5fc0: 00000000 00e9a010 00e9a050 00000026 004fd000 76f05ce8 7ea7981c 7ea7a81c
[ 558.049811] 5fe0: 004fd198 7ea79814 0049cc9b 76cd7796 00010030 7ea7981c 00000000 00000000
[ 558.061386] [<802a4da0>] (__d_lookup_rcu) from [<80295cc4>] (lookup_fast+0x4c/0x2c8)
[ 558.072944] [<80295cc4>] (lookup_fast) from [<80298140>] (walk_component+0x3c/0x2dc)
[ 558.084330] [<80298140>] (walk_component) from [<8029856c>] (link_path_walk+0x18c/0x4b0)
[ 558.095582] [<8029856c>] (link_path_walk) from [<802988c4>] (path_parentat+0x34/0x6c)
[ 558.106851] [<802988c4>] (path_parentat) from [<8029a4b4>] (filename_parentat+0x7c/0x104)
[ 558.117923] [<8029a4b4>] (filename_parentat) from [<8029b984>] (SyS_renameat2+0xd4/0x48c)
[ 558.129156] [<8029b984>] (SyS_renameat2) from [<8029bd9c>] (SyS_rename+0x34/0x3c)
[ 558.140092] [<8029bd9c>] (SyS_rename) from [<80108060>] (ret_fast_syscall+0x0/0x28)
[ 558.150966] Code: ea000002 e5944000 e3540000 0a000028 (e5141004)
[ 558.161756] ---[ end trace 124dc21b9499878a ]---
[ 560.624738] Alignment trap: not handling instruction e1b04f9f at [<80566d48>]
[ 560.635458] Unhandled fault: alignment exception (0x001) at 0x9ac47754
[ 560.646194] pgd = acecc000
[ 560.656802] [9ac47754] *pgd=1ac1141e(bad)
[ 560.667391] Internal error: : 1 [#4] SMP ARM
[ 560.677894] Modules linked in: dm_mod dax fuse loop hci_uart bluetooth ecdh_generic sg uio_pdrv_genirq uio lirc_rpi(C) lirc_dev fixed frandom ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip_tables x_tables ipv6 snd_bcm2835(C) snd_pcm snd_timer snd brcmfmac cfg80211 rfkill brcmutil evdev rpcsec_gss_krb5 tun uinput
[ 560.700191] CPU: 3 PID: 4194 Comm: PeripBusUSBUdev Tainted: G D C 4.14.29+ #1
[ 560.711520] Hardware name: BCM2835
[ 560.724080] task: 81945a00 task.stack: 9e712000
[ 560.737866] PC is at lockref_put_return+0x3c/0x94
[ 560.750567] LR is at dput+0x40/0x2d0
[ 560.761780] pc : [<80566d4c>] lr : [<802a1abc>] psr: 20060013
[ 560.773122] sp : 9e713de0 ip : 9e713e00 fp : 9e713dfc
[ 560.784351] r10: 00000000 r9 : 9e712000 r8 : 9e713f60
[ 560.795460] r7 : 00000001 r6 : 00010001 r5 : 00000001 r4 : 00010001
[ 560.806753] r3 : 00000000 r2 : 00010001 r1 : 00000000 r0 : 9ac47754
[ 560.817978] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 560.829007] Control: 10c5383d Table: 2cecc06a DAC: 00000055
[ 560.839867] Process PeripBusUSBUdev (pid: 4194, stack limit = 0x9e712210)
[ 560.851294] Stack: (0x9e713de0 to 0x9e714000)
[ 560.863891] 3de0: 9ac47704 00080040 9ac47754 00000041 9e713e24 9e713e00 802a1abc 80566d1c
[ 560.876801] 3e00: 00000000 9e713e78 9e713f60 00000041 9e713f60 9e712000 9e713e44 9e713e28
[ 560.887838] 3e20: 80294b9c 802a1a88 9e713e78 fffffffe 9e713f60 00000041 9e713e74 9e713e48
[ 560.900010] 3e40: 802989bc 80294b5c 9e6683f8 af57c6bc 00000000 00000000 00000001 8c6f5000
[ 560.915033] 3e60: 9e713e78 00000001 9e713f24 9e713e78 8029a5d8 80298908 ae990310 9ac47704
[ 560.929842] 3e80: e73d77c1 00000006 8c6f5025 00000000 ae990c10 ae7af660 ae7db2b0 00000001
[ 560.942629] 3ea0: 9e713dd0 000003be 00000000 00000000 00000000 9e713eb8 00000000 00000000
[ 560.955273] 3ec0: 00001000 8c6f6000 00000000 00000001 80d0459c 8c6f5000 80d0459c 6b2fea18
[ 560.966619] 3ee0: 00000000 00000001 8c6f5000 00000000 8029a30c 00000002 ffffff9c 00000001
[ 560.978523] 3f00: ffffff9c 00000001 ffffff9c 9e713f60 ffffff9c 6b2fea18 9e713f4c 9e713f28
[ 560.992103] 3f20: 8029a720 8029a548 00000000 00000000 9e713f4c 00000001 00000000 acb3e980
[ 561.005850] 3f40: 9e713f94 9e713f50 80287344 8029a6d8 00000000 00000000 aaa67500 00000000
[ 561.017377] 3f60: 00000000 00000000 00000005 00000000 5c21ee28 76f78ce8 00000021 80108204
[ 561.029029] 3f80: 9e712000 00000000 9e713fa4 9e713f98 802874c4 802872b4 00000000 9e713fa8
[ 561.040579] 3fa0: 80108060 802874ac 00000000 5c21ee28 6b2fea18 00000000 00000000 6b2fea33
[ 561.052969] 3fc0: 00000000 5c21ee28 76f78ce8 00000021 6b2fea18 6b2fea48 716d7b30 ffffffea
[ 561.068944] 3fe0: 75eebf10 6b2fea04 75ee4b7b 759c1b66 20060030 6b2fea18 aa98abba faaaaaea
[ 561.083256] [<80566d4c>] (lockref_put_return) from [<802a1abc>] (dput+0x40/0x2d0)
[ 561.094752] [<802a1abc>] (dput) from [<80294b9c>] (terminate_walk+0x4c/0xc0)
[ 561.106786] [<80294b9c>] (terminate_walk) from [<802989bc>] (path_lookupat+0xc0/0x204)
[ 561.120543] [<802989bc>] (path_lookupat) from [<8029a5d8>] (filename_lookup+0x9c/0xf8)
[ 561.133721] [<8029a5d8>] (filename_lookup) from [<8029a720>] (user_path_at_empty+0x54/0x5c)
[ 561.144836] [<8029a720>] (user_path_at_empty) from [<80287344>] (SyS_faccessat+0x9c/0x1f8)
[ 561.155787] [<80287344>] (SyS_faccessat) from [<802874c4>] (SyS_access+0x24/0x28)
[ 561.166755] [<802874c4>] (SyS_access) from [<80108060>] (ret_fast_syscall+0x0/0x28)
[ 561.177608] Code: e1a07005 da000015 f590f000 e1b04f9f (e1340006)
[ 561.188475] ---[ end trace 124dc21b9499878b ]---
[ 627.422503] Unable to handle kernel NULL pointer dereference at virtual address 0000000d
[ 627.436018] pgd = 82af0000
[ 627.449159] [0000000d] *pgd=00000000
[ 627.460412] Internal error: Oops: 5 [#5] SMP ARM
[ 627.470877] Modules linked in: dm_mod dax fuse loop hci_uart bluetooth ecdh_generic sg uio_pdrv_genirq uio lirc_rpi(C) lirc_dev fixed frandom ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip_tables x_tables ipv6 snd_bcm2835(C) snd_pcm snd_timer snd brcmfmac cfg80211 rfkill brcmutil evdev rpcsec_gss_krb5 tun uinput
[ 627.492654] CPU: 0 PID: 10887 Comm: sudo Tainted: G D C 4.14.29+ #1
[ 627.503546] Hardware name: BCM2835
[ 627.514368] task: 91ab3c00 task.stack: 8287a000
[ 627.525158] PC is at locks_remove_posix+0x30/0x14c
[ 627.535881] LR is at filp_close+0x68/0x8c
[ 627.547086] pc : [<802e08b0>] lr : [<80286ac4>] psr: 20000013
[ 627.557884] sp : 8287beb0 ip : 8287bf58 fp : 8287bf54
[ 627.568690] r10: 00000000 r9 : 8287a000 r8 : 80108204
[ 627.579439] r7 : 00000006 r6 : acc63300 r5 : 9d640180 r4 : ae690440
[ 627.590265] r3 : 00000001 r2 : ace99fc0 r1 : acc63300 r0 : 9d640180
[ 627.601025] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 627.611944] Control: 10c5383d Table: 02af006a DAC: 00000055
[ 627.622831] Process sudo (pid: 10887, stack limit = 0x8287a210)
[ 627.633779] Stack: (0x8287beb0 to 0x8287c000)
[ 627.644595] bea0: 802fe824 91ab3c00 00000041 802a8f5c
[ 627.655547] bec0: 00000004 00000000 00000000 00000100 81efc688 80d093bc 00000017 808ac294
[ 627.666714] bee0: 76e3be2c 8287bfb0 7e94f750 808a8780 8287bf14 8287bf00 808a8780 806fbae8
[ 627.677972] bf00: add51c00 add51d74 8287bf34 8287bf18 806fbae8 808a7758 add52400 7f0220bc
[ 627.689092] bf20: add52400 add52444 8287bf54 00000000 9d640180 acc63300 00000006 80108204
[ 627.699934] bf40: 8287a000 00000000 8287bf74 8287bf58 80286ac4 802e088c 0000003c acc63300
[ 627.710825] bf60: 9d640180 00000006 8287bf94 8287bf78 802aad38 80286a68 76f39218 0000000b
[ 627.721610] bf80: 00000000 00000006 8287bfa4 8287bf98 80286b18 802aac7c 00000000 8287bfa8
[ 627.732532] bfa0: 80108060 80286af4 76f39218 0000000b 0000003c 7e94f750 76f38b5c 76f38b5c
[ 627.743512] bfc0: 76f39218 0000000b 00000000 00000006 022b85d0 7e94f750 76f76ce8 0000003c
[ 627.754665] bfe0: 7e94f728 7e94f718 76f38b6c 76e10fc2 60000030 0000003c 00000000 00000000
[ 627.765898] [<802e08b0>] (locks_remove_posix) from [<80286ac4>] (filp_close+0x68/0x8c)
[ 627.777075] [<80286ac4>] (filp_close) from [<802aad38>] (__close_fd+0xc8/0xec)
[ 627.788388] [<802aad38>] (__close_fd) from [<80286b18>] (SyS_close+0x30/0x58)
[ 627.799587] [<80286b18>] (SyS_close) from [<80108060>] (ret_fast_syscall+0x0/0x28)
[ 627.810901] Code: e59430e8 f57ff05b e3530000 0a000025 (e5b3200c)
[ 627.823021] ---[ end trace 124dc21b9499878c ]---
[ 627.851770] Unable to handle kernel NULL pointer dereference at virtual address 0000000d
[ 627.863130] pgd = 80004000
[ 627.874478] [0000000d] *pgd=00000000
[ 627.885738] Internal error: Oops: 5 [#6] SMP ARM
[ 627.896909] Modules linked in: dm_mod dax fuse loop hci_uart bluetooth ecdh_generic sg uio_pdrv_genirq uio lirc_rpi(C) lirc_dev fixed frandom ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip_tables x_tables ipv6 snd_bcm2835(C) snd_pcm snd_timer snd brcmfmac cfg80211 rfkill brcmutil evdev rpcsec_gss_krb5 tun uinput
[ 627.920757] CPU: 3 PID: 10879 Comm: sudo Tainted: G D C 4.14.29+ #1
[ 627.932515] Hardware name: BCM2835
[ 627.944207] task: 91ab6900 task.stack: aeb86000
[ 627.955689] PC is at locks_remove_posix+0x30/0x14c
[ 627.967555] LR is at filp_close+0x68/0x8c
[ 627.979366] pc : [<802e08b0>] lr : [<80286ac4>] psr: 28070013
[ 627.994526] sp : aeb87d08 ip : aeb87db0 fp : aeb87dac
[ 628.006388] r10: 0000000b r9 : 8d5bba00 r8 : 00000004
[ 628.017356] r7 : acc63a00 r6 : acc63a00 r5 : 9d640180 r4 : ae690440
[ 628.028340] r3 : 00000001 r2 : 9d640180 r1 : acc63a00 r0 : 9d640180
[ 628.039180] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 628.050082] Control: 10c5383d Table: 2cecc06a DAC: 00000055
[ 628.060845] Process sudo (pid: 10879, stack limit = 0xaeb86210)
[ 628.071621] Stack: (0xaeb87d08 to 0xaeb88000)
[ 628.082270] 7d00: 802777a0 801edc50 00000000 80d87c00 ac80efc0 af2bfff0
[ 628.093150] 7d20: 8012000e 00000001 ac80efc0 00000001 48070013 000b21eb aeb87d84 8012000e
[ 628.104069] 7d40: 80224d2c 808a8780 aeb87d6c aeb87d58 808a8780 806fbae8 add51c00 add51d74
[ 628.115133] 7d60: aeb87d8c aeb87d70 806fbae8 808a7758 add52400 7f0220bc add52400 add52444
[ 628.126354] 7d80: aeb87dac 00000000 9d640180 acc63a00 acc63a00 00000004 8d5bba00 0000000b
[ 628.137591] 7da0: aeb87dcc aeb87db0 80286ac4 802e088c 00000009 000000f0 00000000 acc63a00
[ 628.149003] 7dc0: aeb87df4 aeb87dd0 802aa864 80286a68 91ab6900 91ab6e40 acc63a00 ac80efc0
[ 628.160356] 7de0: 00000001 ac80eff8 aeb87e14 aeb87df8 802aa974 802aa7bc 91ab6900 00000000
[ 628.171934] 7e00: 00000544 ac80efc0 aeb87e54 aeb87e18 80121d6c 802aa928 aeb87e74 aeb87e28
[ 628.183447] 7e20: aeb87edc aeb87fb0 00000000 0000000b 82e42100 aeb87edc aeb86000 00106001
[ 628.194987] 7e40: aeb86000 0000000b aeb87e74 aeb87e58 8012260c 801219e0 00000000 8bf6da08
[ 628.206554] 7e60: aeb87edc aeb86000 aeb87ec4 aeb87e78 8012d9f4 801225cc 80d02040 418004fc
[ 628.218157] 7e80: 80d03d68 aeb87ec8 82e42100 8bf6de44 8bf6d940 000000a0 0000000b 76da3574
[ 628.230003] 7ea0: aeb87ec8 aeb87fb0 76da3576 00000000 aeb86000 00000000 aeb87f8c aeb87ec8
[ 628.241510] 7ec0: 8010b318 8012d6c8 aeb87ef4 aeb87ed8 8012d084 8012cf08 00000000 0000000b
[ 628.252971] 7ee0: 00000000 00000000 00002a7f 00000000 8bf6d968 00000001 91ab6900 00000000
[ 628.264251] 7f00: 00000000 00002a7f 00000000 8bf6d968 00000001 91ab6900 00000001 aeb87f68
[ 628.275572] 7f20: aeb87f64 aeb87f30 8012f17c 801edc50 91ab6e44 00000002 7e94fa98 00000000
[ 628.287125] 7f40: 00000002 7e94fa98 000000ae 80108204 aeb86000 00000000 aeb87fa4 aeb87f68
[ 628.298685] 7f60: 8012f6f0 00000001 aeb86010 80108204 aeb87fb0 80108204 aeb86000 00000000
[ 628.310431] 7f80: aeb87fac aeb87f90 8010b820 8010b260 7e94fa98 0000000b 0000000b 00000025
[ 628.322157] 7fa0: 00000000 aeb87fb0 80108094 8010b774 00000000 0000000b 453b0700 453b0700
[ 628.334017] 7fc0: 7e94fa98 0000000b 0000000b 00000025 022b5c58 004e516c 00000000 7e94fa08
[ 628.345896] 7fe0: 004f6dd8 7e94f9b4 004d2d5b 76da3576 20040030 00002a7f 000001b8 00000000
[ 628.357879] [<802e08b0>] (locks_remove_posix) from [<80286ac4>] (filp_close+0x68/0x8c)
[ 628.369957] [<80286ac4>] (filp_close) from [<802aa864>] (put_files_struct+0xb4/0x10c)
[ 628.381868] [<802aa864>] (put_files_struct) from [<802aa974>] (exit_files+0x58/0x5c)
[ 628.393828] [<802aa974>] (exit_files) from [<80121d6c>] (do_exit+0x398/0xba0)
[ 628.405659] [<80121d6c>] (do_exit) from [<8012260c>] (do_group_exit+0x4c/0xe4)
[ 628.417476] [<8012260c>] (do_group_exit) from [<8012d9f4>] (get_signal+0x338/0x6e0)
[ 628.429281] [<8012d9f4>] (get_signal) from [<8010b318>] (do_signal+0xc4/0x3e4)
[ 628.440899] [<8010b318>] (do_signal) from [<8010b820>] (do_work_pending+0xb8/0xd0)
[ 628.452491] [<8010b820>] (do_work_pending) from [<80108094>] (slow_work_pending+0xc/0x20)
[ 628.463887] Code: e59430e8 f57ff05b e3530000 0a000025 (e5b3200c)
[ 628.475205] ---[ end trace 124dc21b9499878d ]---
[ 628.488855] Fixing recursive fault but reboot is needed!
Se você tiver vcgencmd, relate a saída de vcgencmd get_throttled .
pelwell
em 22 mar. 2018
Hmm, isso é interessante ...
Todos os rastreamentos de pilha nessas mensagens OOPS do kernel não implicam absolutamente nada na pilha de rede, eles apenas têm coisas do kernel do núcleo genérico e funções da camada VFS referenciadas.
A reclamação sobre uma desreferência do ponteiro NULL do kernel em um endereço virtual muito baixo também é um tanto suspeita. Coisas como essa geralmente são indicativas de falha de hardware ou de um driver de kernel malcomportado rabiscando em locais de memória que não deveria tocar.
Ferroin
em 22 mar. 2018
Todos os rastreamentos de pilha nessas mensagens OOPS do kernel não implicam absolutamente nada na pilha de rede, eles apenas têm coisas do kernel do núcleo genérico e funções da camada VFS referenciadas.
Eu sei, será que dados corrompidos lidos do disco USB causaram isso?
mkreisl
em 22 mar. 2018
'Portado' o script de backup para Raspbian, e execute-o lá para fazer backup de uma das minhas partições btrfs. Resultado semelhante, não terminou. btrfs enviar / receber stucks, nada nos logs. Testado com kernel 4.14.27-v7 + original e meu kernel 4.15.10+ e, claro, o backup foi executado com sucesso no Pi3B
@pelwell
vcgencmd get_throttled
throttled=0x0
Obrigado - isso exclui um problema de fonte de alimentação.
pelwell
em 22 mar. 2018
Obrigado - isso exclui um problema de fonte de alimentação.
Já tentei diferentes PSUs, geralmente usando PSU 2.5A novo para Pi3B + e um mais antigo (2A) para Pi3B
mkreisl
em 22 mar. 2018
Sim, foi o que você disse, mas prefiro ouvir do Pi.
pelwell
em 22 mar. 2018
@pelwell
Há algum teste que posso executar para ter certeza absoluta de que o hardware está ok?
A propósito, eu tenho problemas semelhantes se o root fs estiver no destino iSCSI e nenhum drive USB estiver conectado e usado.
mkreisl
em 22 mar. 2018
@pelwell @Ferroin
Ah, e antes que eu esqueça:
Se eu estiver usando WLAN onboard em vez de ethernet onboard, os problemas ainda estão lá
e já mudou o cabo de rede e a porta no switch de rede
e mudar de root para cartão SD não faz nenhuma diferença, conseguindo isso no meu teste final de hoje:
[ 515.046170] CIFS VFS: sends on sock a715d500 stuck for 15 seconds
[ 515.046196] CIFS VFS: Error -11 sending data on socket to server
[ 517.443871] systemd-logind[3010]: New session c2 of user root.
[ 530.166192] CIFS VFS: sends on sock a715d500 stuck for 15 seconds
[ 530.166217] CIFS VFS: Error -11 sending data on socket to server
[ 540.648102] Status code returned 0xc0000008 NT_STATUS_INVALID_HANDLE
[ 540.648134] CIFS VFS: Send error in read = -9
[ 540.648161] print_req_error: I/O error, dev loop0, sector 231328
[ 540.648195] BTRFS error (device dm-1): bdev /dev/mapper/loop0p2 errs: wr 0, rd 1, flush 0, corrupt 0, gen 0
[ 735.206538] INFO: task kworker/u8:2:219 blocked for more than 120 seconds.
[ 735.206553] Tainted: G C 4.14.29+ #1
[ 735.206558] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 735.206567] kworker/u8:2 D 0 219 2 0x00000000
[ 735.206596] Workqueue: writeback wb_workfn (flush-btrfs-3)
[ 735.206633] [<808a5ecc>] (__schedule) from [<808a6544>] (schedule+0x50/0xa8)
[ 735.206652] [<808a6544>] (schedule) from [<80476418>] (btrfs_tree_lock+0x15c/0x278)
[ 735.206672] [<80476418>] (btrfs_tree_lock) from [<804578e0>] (lock_extent_buffer_for_io+0xec/0x270)
[ 735.206694] [<804578e0>] (lock_extent_buffer_for_io) from [<8045b160>] (btree_write_cache_pages+0x248/0x344)
[ 735.206716] [<8045b160>] (btree_write_cache_pages) from [<80422eb0>] (btree_writepages+0x84/0x8c)
[ 735.206734] [<80422eb0>] (btree_writepages) from [<8022edb4>] (do_writepages+0x30/0x8c)
[ 735.206750] [<8022edb4>] (do_writepages) from [<802bb208>] (__writeback_single_inode+0x44/0x434)
[ 735.206766] [<802bb208>] (__writeback_single_inode) from [<802bbb08>] (writeback_sb_inodes+0x214/0x4c4)
[ 735.206781] [<802bbb08>] (writeback_sb_inodes) from [<802bbe48>] (__writeback_inodes_wb+0x90/0xd0)
[ 735.206797] [<802bbe48>] (__writeback_inodes_wb) from [<802bc120>] (wb_writeback+0x298/0x33c)
[ 735.206811] [<802bc120>] (wb_writeback) from [<802bc9b8>] (wb_workfn+0xdc/0x4d8)
[ 735.206831] [<802bc9b8>] (wb_workfn) from [<801374b8>] (process_one_work+0x158/0x454)
[ 735.206850] [<801374b8>] (process_one_work) from [<80137810>] (worker_thread+0x5c/0x5b0)
[ 735.206868] [<80137810>] (worker_thread) from [<8013d8a4>] (kthread+0x13c/0x16c)
[ 735.206886] [<8013d8a4>] (kthread) from [<8010810c>] (ret_from_fork+0x14/0x28)
[ 735.206920] INFO: task kworker/u8:3:399 blocked for more than 120 seconds.
[ 735.206926] Tainted: G C 4.14.29+ #1
[ 735.206931] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 735.206936] kworker/u8:3 D 0 399 2 0x00000000
[ 735.206954] Workqueue: btrfs-endio-write btrfs_endio_write_helper
[ 735.206972] [<808a5ecc>] (__schedule) from [<808a6544>] (schedule+0x50/0xa8)
[ 735.206988] [<808a6544>] (schedule) from [<808aa12c>] (schedule_timeout+0x1d0/0x3e4)
[ 735.207005] [<808aa12c>] (schedule_timeout) from [<808a71cc>] (wait_for_common+0xc0/0x184)
[ 735.207021] [<808a71cc>] (wait_for_common) from [<808a72b0>] (wait_for_completion+0x20/0x24)
[ 735.207036] [<808a72b0>] (wait_for_completion) from [<8040c478>] (btrfs_async_run_delayed_refs+0x12c/0x14c)
[ 735.207053] [<8040c478>] (btrfs_async_run_delayed_refs) from [<8042d7ec>] (__btrfs_end_transaction+0x228/0x324)
[ 735.207069] [<8042d7ec>] (__btrfs_end_transaction) from [<8042d904>] (btrfs_end_transaction+0x1c/0x20)
[ 735.207085] [<8042d904>] (btrfs_end_transaction) from [<80438b40>] (btrfs_finish_ordered_io+0x230/0x848)
[ 735.207102] [<80438b40>] (btrfs_finish_ordered_io) from [<8043955c>] (finish_ordered_fn+0x1c/0x20)
[ 735.207118] [<8043955c>] (finish_ordered_fn) from [<8046a1d8>] (normal_work_helper+0xb0/0x3e0)
[ 735.207135] [<8046a1d8>] (normal_work_helper) from [<8046a8f0>] (btrfs_endio_write_helper+0x1c/0x20)
[ 735.207152] [<8046a8f0>] (btrfs_endio_write_helper) from [<801374b8>] (process_one_work+0x158/0x454)
[ 735.207170] [<801374b8>] (process_one_work) from [<80137810>] (worker_thread+0x5c/0x5b0)
[ 735.207187] [<80137810>] (worker_thread) from [<8013d8a4>] (kthread+0x13c/0x16c)
[ 735.207203] [<8013d8a4>] (kthread) from [<8010810c>] (ret_from_fork+0x14/0x28)
[ 735.207217] INFO: task kworker/u8:6:759 blocked for more than 120 seconds.
[ 735.207224] Tainted: G C 4.14.29+ #1
[ 735.207229] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 735.207233] kworker/u8:6 D 0 759 2 0x00000000
[ 735.207250] Workqueue: btrfs-extent-refs btrfs_extent_refs_helper
[ 735.207269] [<808a5ecc>] (__schedule) from [<808a6544>] (schedule+0x50/0xa8)
[ 735.207284] [<808a6544>] (schedule) from [<80475e2c>] (btrfs_tree_read_lock+0x120/0x198)
[ 735.207303] [<80475e2c>] (btrfs_tree_read_lock) from [<803f9660>] (btrfs_read_lock_root_node+0x38/0x50)
[ 735.207321] [<803f9660>] (btrfs_read_lock_root_node) from [<803ff188>] (btrfs_search_slot+0x8b0/0xb10)
[ 735.207339] [<803ff188>] (btrfs_search_slot) from [<80400f10>] (btrfs_insert_empty_items+0x7c/0xd4)
[ 735.207357] [<80400f10>] (btrfs_insert_empty_items) from [<8040f01c>] (__btrfs_run_delayed_refs+0xe90/0x16fc)
[ 735.207374] [<8040f01c>] (__btrfs_run_delayed_refs) from [<80412d9c>] (btrfs_run_delayed_refs+0x9c/0x310)
[ 735.207390] [<80412d9c>] (btrfs_run_delayed_refs) from [<804130c4>] (delayed_ref_async_start+0xb4/0xc0)
[ 735.207405] [<804130c4>] (delayed_ref_async_start) from [<8046a1d8>] (normal_work_helper+0xb0/0x3e0)
[ 735.207419] [<8046a1d8>] (normal_work_helper) from [<8046a990>] (btrfs_extent_refs_helper+0x1c/0x20)
[ 735.207437] [<8046a990>] (btrfs_extent_refs_helper) from [<801374b8>] (process_one_work+0x158/0x454)
[ 735.207455] [<801374b8>] (process_one_work) from [<80137810>] (worker_thread+0x5c/0x5b0)
[ 735.207471] [<80137810>] (worker_thread) from [<8013d8a4>] (kthread+0x13c/0x16c)
[ 735.207487] [<8013d8a4>] (kthread) from [<8010810c>] (ret_from_fork+0x14/0x28)
[ 735.207625] INFO: task btrfs-transacti:8152 blocked for more than 120 seconds.
[ 735.207632] Tainted: G C 4.14.29+ #1
[ 735.207637] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 735.207641] btrfs-transacti D 0 8152 2 0x00000000
[ 735.207663] [<808a5ecc>] (__schedule) from [<808a6544>] (schedule+0x50/0xa8)
[ 735.207678] [<808a6544>] (schedule) from [<8014b128>] (io_schedule+0x20/0x40)
[ 735.207693] [<8014b128>] (io_schedule) from [<8021cd60>] (wait_on_page_bit+0x120/0x140)
[ 735.207711] [<8021cd60>] (wait_on_page_bit) from [<80459a00>] (read_extent_buffer_pages+0x258/0x33c)
[ 735.207731] [<80459a00>] (read_extent_buffer_pages) from [<80422350>] (btree_read_extent_buffer_pages+0xb0/0x120)
[ 735.207747] [<80422350>] (btree_read_extent_buffer_pages) from [<80423818>] (read_tree_block+0x38/0x54)
[ 735.207763] [<80423818>] (read_tree_block) from [<803f7914>] (read_node_slot+0xc4/0x100)
[ 735.207779] [<803f7914>] (read_node_slot) from [<803fd508>] (push_leaf_right+0xb8/0x1f0)
[ 735.207796] [<803fd508>] (push_leaf_right) from [<803fe6c8>] (split_leaf+0x5f4/0x804)
[ 735.207813] [<803fe6c8>] (split_leaf) from [<803ff270>] (btrfs_search_slot+0x998/0xb10)
[ 735.207830] [<803ff270>] (btrfs_search_slot) from [<80400f10>] (btrfs_insert_empty_items+0x7c/0xd4)
[ 735.207847] [<80400f10>] (btrfs_insert_empty_items) from [<8040f01c>] (__btrfs_run_delayed_refs+0xe90/0x16fc)
[ 735.207863] [<8040f01c>] (__btrfs_run_delayed_refs) from [<80412d9c>] (btrfs_run_delayed_refs+0x9c/0x310)
[ 735.207879] [<80412d9c>] (btrfs_run_delayed_refs) from [<8042c378>] (btrfs_commit_transaction+0x38/0xc2c)
[ 735.207893] [<8042c378>] (btrfs_commit_transaction) from [<804274bc>] (transaction_kthread+0x1b4/0x1c8)
[ 735.207908] [<804274bc>] (transaction_kthread) from [<8013d8a4>] (kthread+0x13c/0x16c)
[ 735.207923] [<8013d8a4>] (kthread) from [<8010810c>] (ret_from_fork+0x14/0x28)
[ 735.207947] INFO: task btrfs:9851 blocked for more than 120 seconds.
[ 735.207953] Tainted: G C 4.14.29+ #1
[ 735.207958] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 735.207963] btrfs D 0 9851 9850 0x00000000
[ 735.207984] [<808a5ecc>] (__schedule) from [<808a6544>] (schedule+0x50/0xa8)
[ 735.207999] [<808a6544>] (schedule) from [<8044fdec>] (btrfs_start_ordered_extent+0x128/0x158)
[ 735.208016] [<8044fdec>] (btrfs_start_ordered_extent) from [<80450394>] (btrfs_wait_ordered_range+0x140/0x18c)
[ 735.208032] [<80450394>] (btrfs_wait_ordered_range) from [<8043b4f0>] (btrfs_truncate+0x54/0x2c8)
[ 735.208048] [<8043b4f0>] (btrfs_truncate) from [<8043c074>] (btrfs_setattr+0x2f4/0x488)
[ 735.208067] [<8043c074>] (btrfs_setattr) from [<802a9318>] (notify_change+0x1cc/0x408)
[ 735.208084] [<802a9318>] (notify_change) from [<80286c98>] (do_truncate+0x90/0xc0)
[ 735.208099] [<80286c98>] (do_truncate) from [<80286eac>] (vfs_truncate+0x1e4/0x25c)
[ 735.208113] [<80286eac>] (vfs_truncate) from [<80286fa0>] (do_sys_truncate+0x7c/0xac)
[ 735.208127] [<80286fa0>] (do_sys_truncate) from [<80287200>] (SyS_truncate64+0x18/0x1c)
[ 735.208143] [<80287200>] (SyS_truncate64) from [<80108060>] (ret_fast_syscall+0x0/0x28)
[ 858.087442] INFO: task kworker/u8:2:219 blocked for more than 120 seconds.
[ 858.087457] Tainted: G C 4.14.29+ #1
[ 858.087462] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 858.087469] kworker/u8:2 D 0 219 2 0x00000000
[ 858.087503] Workqueue: writeback wb_workfn (flush-btrfs-3)
[ 858.087538] [<808a5ecc>] (__schedule) from [<808a6544>] (schedule+0x50/0xa8)
[ 858.087557] [<808a6544>] (schedule) from [<80476418>] (btrfs_tree_lock+0x15c/0x278)
[ 858.087579] [<80476418>] (btrfs_tree_lock) from [<804578e0>] (lock_extent_buffer_for_io+0xec/0x270)
[ 858.087601] [<804578e0>] (lock_extent_buffer_for_io) from [<8045b160>] (btree_write_cache_pages+0x248/0x344)
[ 858.087624] [<8045b160>] (btree_write_cache_pages) from [<80422eb0>] (btree_writepages+0x84/0x8c)
[ 858.087642] [<80422eb0>] (btree_writepages) from [<8022edb4>] (do_writepages+0x30/0x8c)
[ 858.087659] [<8022edb4>] (do_writepages) from [<802bb208>] (__writeback_single_inode+0x44/0x434)
[ 858.087675] [<802bb208>] (__writeback_single_inode) from [<802bbb08>] (writeback_sb_inodes+0x214/0x4c4)
[ 858.087690] [<802bbb08>] (writeback_sb_inodes) from [<802bbe48>] (__writeback_inodes_wb+0x90/0xd0)
[ 858.087705] [<802bbe48>] (__writeback_inodes_wb) from [<802bc120>] (wb_writeback+0x298/0x33c)
[ 858.087719] [<802bc120>] (wb_writeback) from [<802bc9b8>] (wb_workfn+0xdc/0x4d8)
[ 858.087739] [<802bc9b8>] (wb_workfn) from [<801374b8>] (process_one_work+0x158/0x454)
[ 858.087758] [<801374b8>] (process_one_work) from [<80137810>] (worker_thread+0x5c/0x5b0)
[ 858.087775] [<80137810>] (worker_thread) from [<8013d8a4>] (kthread+0x13c/0x16c)
[ 858.087793] [<8013d8a4>] (kthread) from [<8010810c>] (ret_from_fork+0x14/0x28)
[ 858.087827] INFO: task kworker/u8:3:399 blocked for more than 120 seconds.
[ 858.087833] Tainted: G C 4.14.29+ #1
[ 858.087838] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 858.087843] kworker/u8:3 D 0 399 2 0x00000000
[ 858.087861] Workqueue: btrfs-endio-write btrfs_endio_write_helper
[ 858.087879] [<808a5ecc>] (__schedule) from [<808a6544>] (schedule+0x50/0xa8)
[ 858.087895] [<808a6544>] (schedule) from [<808aa12c>] (schedule_timeout+0x1d0/0x3e4)
[ 858.087912] [<808aa12c>] (schedule_timeout) from [<808a71cc>] (wait_for_common+0xc0/0x184)
[ 858.087929] [<808a71cc>] (wait_for_common) from [<808a72b0>] (wait_for_completion+0x20/0x24)
[ 858.087944] [<808a72b0>] (wait_for_completion) from [<8040c478>] (btrfs_async_run_delayed_refs+0x12c/0x14c)
[ 858.087961] [<8040c478>] (btrfs_async_run_delayed_refs) from [<8042d7ec>] (__btrfs_end_transaction+0x228/0x324)
[ 858.087976] [<8042d7ec>] (__btrfs_end_transaction) from [<8042d904>] (btrfs_end_transaction+0x1c/0x20)
[ 858.087994] [<8042d904>] (btrfs_end_transaction) from [<80438b40>] (btrfs_finish_ordered_io+0x230/0x848)
[ 858.088011] [<80438b40>] (btrfs_finish_ordered_io) from [<8043955c>] (finish_ordered_fn+0x1c/0x20)
[ 858.088027] [<8043955c>] (finish_ordered_fn) from [<8046a1d8>] (normal_work_helper+0xb0/0x3e0)
[ 858.088042] [<8046a1d8>] (normal_work_helper) from [<8046a8f0>] (btrfs_endio_write_helper+0x1c/0x20)
[ 858.088060] [<8046a8f0>] (btrfs_endio_write_helper) from [<801374b8>] (process_one_work+0x158/0x454)
[ 858.088077] [<801374b8>] (process_one_work) from [<80137810>] (worker_thread+0x5c/0x5b0)
[ 858.088094] [<80137810>] (worker_thread) from [<8013d8a4>] (kthread+0x13c/0x16c)
[ 858.088109] [<8013d8a4>] (kthread) from [<8010810c>] (ret_from_fork+0x14/0x28)
[ 858.088124] INFO: task kworker/u8:6:759 blocked for more than 120 seconds.
[ 858.088130] Tainted: G C 4.14.29+ #1
[ 858.088135] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 858.088140] kworker/u8:6 D 0 759 2 0x00000000
[ 858.088157] Workqueue: btrfs-extent-refs btrfs_extent_refs_helper
[ 858.088176] [<808a5ecc>] (__schedule) from [<808a6544>] (schedule+0x50/0xa8)
[ 858.088191] [<808a6544>] (schedule) from [<80475e2c>] (btrfs_tree_read_lock+0x120/0x198)
[ 858.088210] [<80475e2c>] (btrfs_tree_read_lock) from [<803f9660>] (btrfs_read_lock_root_node+0x38/0x50)
[ 858.088228] [<803f9660>] (btrfs_read_lock_root_node) from [<803ff188>] (btrfs_search_slot+0x8b0/0xb10)
[ 858.088246] [<803ff188>] (btrfs_search_slot) from [<80400f10>] (btrfs_insert_empty_items+0x7c/0xd4)
[ 858.088264] [<80400f10>] (btrfs_insert_empty_items) from [<8040f01c>] (__btrfs_run_delayed_refs+0xe90/0x16fc)
[ 858.088281] [<8040f01c>] (__btrfs_run_delayed_refs) from [<80412d9c>] (btrfs_run_delayed_refs+0x9c/0x310)
[ 858.088297] [<80412d9c>] (btrfs_run_delayed_refs) from [<804130c4>] (delayed_ref_async_start+0xb4/0xc0)
[ 858.088312] [<804130c4>] (delayed_ref_async_start) from [<8046a1d8>] (normal_work_helper+0xb0/0x3e0)
[ 858.088326] [<8046a1d8>] (normal_work_helper) from [<8046a990>] (btrfs_extent_refs_helper+0x1c/0x20)
[ 858.088344] [<8046a990>] (btrfs_extent_refs_helper) from [<801374b8>] (process_one_work+0x158/0x454)
[ 858.088362] [<801374b8>] (process_one_work) from [<80137810>] (worker_thread+0x5c/0x5b0)
[ 858.088378] [<80137810>] (worker_thread) from [<8013d8a4>] (kthread+0x13c/0x16c)
[ 858.088394] [<8013d8a4>] (kthread) from [<8010810c>] (ret_from_fork+0x14/0x28)
[ 858.088532] INFO: task btrfs-transacti:8152 blocked for more than 120 seconds.
[ 858.088539] Tainted: G C 4.14.29+ #1
[ 858.088544] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 858.088548] btrfs-transacti D 0 8152 2 0x00000000
[ 858.088570] [<808a5ecc>] (__schedule) from [<808a6544>] (schedule+0x50/0xa8)
[ 858.088585] [<808a6544>] (schedule) from [<8014b128>] (io_schedule+0x20/0x40)
[ 858.088600] [<8014b128>] (io_schedule) from [<8021cd60>] (wait_on_page_bit+0x120/0x140)
[ 858.088617] [<8021cd60>] (wait_on_page_bit) from [<80459a00>] (read_extent_buffer_pages+0x258/0x33c)
[ 858.088637] [<80459a00>] (read_extent_buffer_pages) from [<80422350>] (btree_read_extent_buffer_pages+0xb0/0x120)
[ 858.088653] [<80422350>] (btree_read_extent_buffer_pages) from [<80423818>] (read_tree_block+0x38/0x54)
[ 858.088669] [<80423818>] (read_tree_block) from [<803f7914>] (read_node_slot+0xc4/0x100)
[ 858.088686] [<803f7914>] (read_node_slot) from [<803fd508>] (push_leaf_right+0xb8/0x1f0)
[ 858.088703] [<803fd508>] (push_leaf_right) from [<803fe6c8>] (split_leaf+0x5f4/0x804)
[ 858.088720] [<803fe6c8>] (split_leaf) from [<803ff270>] (btrfs_search_slot+0x998/0xb10)
[ 858.088737] [<803ff270>] (btrfs_search_slot) from [<80400f10>] (btrfs_insert_empty_items+0x7c/0xd4)
[ 858.088754] [<80400f10>] (btrfs_insert_empty_items) from [<8040f01c>] (__btrfs_run_delayed_refs+0xe90/0x16fc)
[ 858.088770] [<8040f01c>] (__btrfs_run_delayed_refs) from [<80412d9c>] (btrfs_run_delayed_refs+0x9c/0x310)
[ 858.088786] [<80412d9c>] (btrfs_run_delayed_refs) from [<8042c378>] (btrfs_commit_transaction+0x38/0xc2c)
[ 858.088800] [<8042c378>] (btrfs_commit_transaction) from [<804274bc>] (transaction_kthread+0x1b4/0x1c8)
[ 858.088814] [<804274bc>] (transaction_kthread) from [<8013d8a4>] (kthread+0x13c/0x16c)
[ 858.088830] [<8013d8a4>] (kthread) from [<8010810c>] (ret_from_fork+0x14/0x28)
[ 858.088854] INFO: task btrfs:9851 blocked for more than 120 seconds.
[ 858.088860] Tainted: G C 4.14.29+ #1
[ 858.088865] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 858.088869] btrfs D 0 9851 9850 0x00000000
[ 858.088891] [<808a5ecc>] (__schedule) from [<808a6544>] (schedule+0x50/0xa8)
[ 858.088906] [<808a6544>] (schedule) from [<8044fdec>] (btrfs_start_ordered_extent+0x128/0x158)
[ 858.088924] [<8044fdec>] (btrfs_start_ordered_extent) from [<80450394>] (btrfs_wait_ordered_range+0x140/0x18c)
[ 858.088941] [<80450394>] (btrfs_wait_ordered_range) from [<8043b4f0>] (btrfs_truncate+0x54/0x2c8)
[ 858.088957] [<8043b4f0>] (btrfs_truncate) from [<8043c074>] (btrfs_setattr+0x2f4/0x488)
[ 858.088975] [<8043c074>] (btrfs_setattr) from [<802a9318>] (notify_change+0x1cc/0x408)
[ 858.088993] [<802a9318>] (notify_change) from [<80286c98>] (do_truncate+0x90/0xc0)
[ 858.089008] [<80286c98>] (do_truncate) from [<80286eac>] (vfs_truncate+0x1e4/0x25c)
[ 858.089022] [<80286eac>] (vfs_truncate) from [<80286fa0>] (do_sys_truncate+0x7c/0xac)
[ 858.089036] [<80286fa0>] (do_sys_truncate) from [<80287200>] (SyS_truncate64+0x18/0x1c)
[ 858.089052] [<80287200>] (SyS_truncate64) from [<80108060>] (ret_fast_syscall+0x0/0x28)
A propósito, o sistema (partição raiz) foi clonado da partição usb para o cartão SD usando o mesmo procedimento de backup e funcionou sem problemas.
mkreisl
em 22 mar. 2018
Você tem outro Pi3B + para experimentar. É realmente muito bizarro, e bizarro sempre me faz pensar que é uma falha de HW.
JamesH65
em 22 mar. 2018
Você tem outro Pi3B + para experimentar. É realmente muito bizarro, e bizarro sempre me faz pensar que é uma falha de HW.
não, infelizmente não
mkreisl
em 22 mar. 2018
Não me parece uma falha de hardware - em caso afirmativo, você esperaria vê-lo em um kernel Raspbian padrão também, e até agora não acho que tenhamos.
pelwell
em 22 mar. 2018
em caso afirmativo, você esperaria vê-lo em um kernel Raspbian padrão também
Já postado. Acontece no Raspbian usando kernel padrão (4.14.27+) também
mkreisl
em 22 mar. 2018
Sim, lendo seu comentário anterior novamente, posso ver o que significa isso.
Você pode tentar limitar os núcleos ARM a 1,2 GHz adicionando o seguinte ao config.txt ?:
arm_freq=1200
@pelwell
Vou tentar isso. Atualmente executando outro teste em uma máquina diferente, com resultado muito estranho
recebendo periodicamente mensagens como esta:
[ 1416.176886] nfs: server kmxbmc not responding, still trying
[ 1417.217789] nfs: server kmxbmc not responding, still trying
[ 1417.575681] nfs: server kmxbmc OK
[ 1417.588839] nfs: server kmxbmc OK
O intervalo é exatamente 239s. Alguma ideia de onde vem esse valor. O compartilhamento NFS é montado da seguinte maneira
kmxbmc:/srv on /mnt type nfs (rw,relatime,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.1.5,mountvers=3,mountport=20048,mountproto=udp,local_lock=none,addr=192.168.1.5)
@pelwell
Não ajuda: desapontado:
mkreisl
em 23 mar. 2018
... e não depende da versão do kernel. 4.9.xx produzindo os mesmos problemas
mkreisl
em 23 mar. 2018
Há um tópico interessante no fórum OSMC sobre um problema de rede 3B +. Quando o usuário conectou seu RPi diretamente ao switch, o problema desapareceu.
RPi 3B (sem +) pode atingir 100 mbps no máximo, então esse problema pode estar relacionado à velocidade mais alta que requer ajustes de rede, ou seja, um buffer maior. Mudar o tamanho da MTU ou cabos Ethernet ou usar diferentes switches de 100 Mbps / 1 Gbps fez alguma diferença?
Seria útil se @mkreisl explicasse como seu RPi está conectado exatamente? Ao trabalhar, quais velocidades RPi 3B e 3B + alcançam?
fieryo
em 23 mar. 2018
@fogosa-
Nada especial. Conectado diretamente ao meu roteador (switch GBit de 4 portas) via cabo Ethernet CAT5 de 5m
Enviando dados de / dev / zero para o servidor 33 MB / s
Recebendo dados do servidor 29 MB / s
Você não leu este tópico completamente. O problema também aparece na conexão WLAN
mkreisl
em 23 mar. 2018
@mkreisl
Alguma saída suspeita no dmesg?
Qual é o MTU de sua interface Ethernet onboard?
Isso ajuda a reduzir o MTU para 1496?
Qual foi a saída de ethtool -S eth0 depois que o problema apareceu?
lategoodbye
em 23 mar. 2018
@lategoodbye
Alguma saída suspeita no dmesg?
Já postou dmesg (veja acima). Mas a saída é extremamente diferente. Às vezes nada, o processo de cópia apenas bloqueia, às vezes o sistema travou completamente, às vezes a mensagem abaixo, às vezes kernel Oops ...
[ 347.207072] CIFS VFS: sends on sock 81c33340 stuck for 15 seconds
[ 347.207099] CIFS VFS: Error -11 sending data on socket to server
[ 362.328036] CIFS VFS: sends on sock 81c33340 stuck for 15 seconds
[ 362.328066] CIFS VFS: Error -11 sending data on socket to server
[ 362.418887] CIFS VFS: Free previous auth_key.response = ad8a3540
[ 368.135439] CIFS VFS: Free previous auth_key.response = 9cd2a840
[ 372.970214] Status code returned 0xc0000128 STATUS_FILE_CLOSED
[ 372.970259] CIFS VFS: Send error in read = -9
[ 372.970297] print_req_error: I/O error, dev loop0, sector 296512
[ 372.970334] BTRFS error (device dm-1): bdev /dev/mapper/loop0p2 errs: wr 0, rd 1, flush 0, corrupt 0, gen 0
[ 389.918475] print_req_error: I/O error, dev loop0, sector 0
[ 389.918755] BTRFS error (device dm-1): bdev /dev/mapper/loop0p2 errs: wr 0, rd 1, flush 1, corrupt 0, gen 0
[ 389.918775] BTRFS warning (device dm-1): chunk 1048576 missing 1 devices, max tolerance is 0 for writeable mount
[ 389.918808] BTRFS: error (device dm-1) in write_all_supers:3670: errno=-5 IO failure (errors while submitting device barriers.)
[ 389.918825] BTRFS info (device dm-1): forced readonly
[ 389.918841] BTRFS warning (device dm-1): Skipping commit of aborted transaction.
[ 389.918851] BTRFS: error (device dm-1) in cleanup_transaction:1873: errno=-5 IO failure
[ 389.918863] BTRFS info (device dm-1): delayed_refs has NO entry
Qual é o MTU de sua interface Ethernet onboard?
Padrão (1500)
Isso ajuda a reduzir o MTU para 1496?
Não
Qual a saída de ethtool -S eth0 depois que o problema apareceu?
NIC statistics:
RX FCS Errors: 0
RX Alignment Errors: 0
Rx Fragment Errors: 0
RX Jabber Errors: 0
RX Undersize Frame Errors: 0
RX Oversize Frame Errors: 0
RX Dropped Frames: 0
RX Unicast Byte Count: 82919099
RX Broadcast Byte Count: 32537
RX Multicast Byte Count: 199380
RX Unicast Frames: 460932
RX Broadcast Frames: 394
RX Multicast Frames: 554
RX Pause Frames: 708426
RX 64 Byte Frames: 329
RX 65 - 127 Byte Frames: 428916
RX 128 - 255 Byte Frames: 2601
RX 256 - 511 Bytes Frames: 592
RX 512 - 1023 Byte Frames: 307
RX 1024 - 1518 Byte Frames: 29135
RX Greater 1518 Byte Frames: 0
EEE RX LPI Transitions: 0
EEE RX LPI Time: 0
TX FCS Errors: 0
TX Excess Deferral Errors: 0
TX Carrier Errors: 0
TX Bad Byte Count: 0
TX Single Collisions: 0
TX Multiple Collisions: 0
TX Excessive Collision: 0
TX Late Collisions: 0
TX Unicast Byte Count: 1673525473
TX Broadcast Byte Count: 4804
TX Multicast Byte Count: 26394
TX Unicast Frames: 1126605
TX Broadcast Frames: 44
TX Multicast Frames: 118
TX Pause Frames: 8
TX 64 Byte Frames: 37
TX 65 - 127 Byte Frames: 13575
TX 128 - 255 Byte Frames: 8217
TX 256 - 511 Bytes Frames: 1747
TX 512 - 1023 Byte Frames: 144
TX 1024 - 1518 Byte Frames: 1103047
TX Greater 1518 Byte Frames: 0
EEE TX LPI Transitions: 0
EEE TX LPI Time: 0
Agora fiz o teste final, coloquei a chave de 100 MBit entre, para forçar um link de 100 MB em vez de 1 GB.
Não faz diferença, agora mandando de volta aquela merda: bravo:
mkreisl
em 23 mar. 2018
O mesmo com samba e compartilhamento (NFS / etx4 ...) Em HDD externo ou SD interno. Após reiniciar seu trabalho perfeitamente por 30/40 minutos e após o kick of share e reconectar novamente e novamente.
Rede funciona perfeitamente (sem ping out ...) Sinto owerload a fila ou algo parecido.
Knoppix1
em 23 mar. 2018
Mesmo problema aqui. Estou usando Samba e USB HDD externo. É bastante aleatório, mas é apenas uma questão de tempo até que aconteça, sem problemas de dmesg indicados, throttled = 0x0. RPi é conectado diretamente ao switch GB de 8 portas via cabo cat5e.
Otw-cz
em 23 mar. 2018
Tenho exatamente o mesmo problema e fico feliz em ver que não estou sozinho nisso, depois de reiniciar posso transferir arquivos através do sftp (usando o filezilla no Windows) sem problemas, mas depois de meia hora ou mais depois de inicializar as transferências don não funciona mais: ele trava após um ou dois segundos de transferência em alta velocidade (18 MBps), depois atinge o tempo limite e tenta se reconectar após 20 segundos, apenas para falhar novamente após um ou dois segundos de transferência. Eu também tentei o mesmo com a transferência dos arquivos do cartão SD (sem hdd conectado) e tem os mesmos problemas, quando coloco o cartão SD em um 3B ele não tem problemas em transferir esses arquivos até mesmo do disco rígido.
Estou usando o Raspbian e o carregador oficial Raspberry Pi, se isso ajudar.
Se for relacionado a hardware, adoraria saber para que possa ser trocado pelo vendedor.
ltctceplrm
em 24 mar. 2018
Parece que a equipe do Raspberry Pi não testou nada antes de lançar o Pi3B +: angry:
mkreisl
em 24 mar. 2018
Sim, isso mesmo, porque acabamos de instalar algum hardware, e nunca
verifiquei se tudo funcionava antes de liberá-lo ...
Ou, por outro lado, talvez passamos um ano fazendo este produto e fizemos,
na verdade, teste, mas nunca viu esse erro?
Também pode valer a pena considerar que já vendemos> 200k B +, e o
número de relatórios desse erro são pequenos em comparação, então talvez seja
alguma interação estranha entre hubs, drivers, firmware e hardware.
Seja o que for, estamos investigando. Minha suspeita é que é um motorista
problema que vamos descobrir, embora às vezes essas coisas possam demorar um
enquanto. No 3B, havia um bug no driver smsc95xx, combinado com um
bug no software brcmfmac, que não chegamos ao fundo para
cerca de um ano - mas era um bug difícil de reproduzir. Mais peças de
software escrito por nós incidentalmente, da mesma forma que o lan78xx
driver ou o firmware do chip, que é presumivelmente a falha aqui, não foi
escrito por nós também.
Em 24 de março de 2018 às 17:47, Manfred Kreisl [email protected] escreveu:
Parece que a equipe do Raspberry Pi não testou nada antes de lançar
o Pi3B + 😠-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/raspberrypi/linux/issues/2449#issuecomment-375911662 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ADqrHVU1fgXWVDM31GSuGtcwNmzeW65yks5thobIgaJpZM4SvXe8
.
-
James Hughes
Engenheiro de software principal,
Raspberry Pi (Trading) Ltd
JamesH65
em 24 mar. 2018
Só gostaria de dizer que a equipe do Raspberry Pi é incrível! Sempre há problemas com novos hardwares e softwares, é normal e impossível testar todas as permutações que existem. Tenho plena confiança de que eles analisarão quaisquer problemas que existam e consertarão quando puderem!
pjgpetecodes
em 24 mar. 2018
@ JamesH65
Você não leu este tópico completamente
Este problema ocorre independentemente se o driver lan78xx é usado ou não.
mkreisl
em 24 mar. 2018
Eu disse que acho que é um problema de driver (lan78xx pode ser o culpado, mas aparentemente não), e depois de folhear o tópico que ainda parece a explicação mais provável. Algo em algum lugar está despejando na memória que não deveria (o que, aliás, foi a causa do bug que mencionei acima, um driver estava despejando em outra alocação de skb de drivers). Como sempre acontece com essas coisas, se pudermos replicar o problema até o fim, teremos uma chance muito melhor de descobri-lo.
JamesH65
em 24 mar. 2018
O esforço para encontrar e corrigir esse problema seria enormemente ajudado se alguém pudesse escrever as etapas para ir de uma imagem de sistema operacional conhecida (idealmente Raspbian, mas não precisa ser) até uma falha observada.
pelwell
em 24 mar. 2018
@pelwell
O esforço para encontrar e corrigir esse problema seria enormemente ajudado se alguém pudesse escrever as etapas para ir de uma imagem de sistema operacional conhecida (idealmente Raspbian, mas não precisa ser) até uma falha observada.
1) Instale o XBian
2) montar o compartilhamento de rede
3) execute o backup dentro de xbian-config, item de menu 6 (copiadora xbian), use o arquivo: / mount-to network-share / test.img como destino
Talvez mais alguns dados precisem ser gravados no fs antes de executar o teste (no meu caso, tenho cerca de 2,5 GB de dados para copiar)
Em suma, isso é o que estou fazendo
ps
Na verdade, escrevi com sucesso 5 imagens depois
1) construção do driver lan78xx como módulo
2) usando wlan e não ethernet, descarregando o módulo lan78xx (isso torna as coisas um pouco melhores, mas o problema ainda permanece e o Kodi trava aleatoriamente)
3) desligando a parte usb executando um script (depois disso tudo parece estar estável e o Kodi não trava)
#!/bin/bash
BUSPOWER="/sys/devices/platform/bcm2708_usb/buspower"
for USB in $(find /sys/devices/platform/soc/ -name *.usb 2>/dev/null); do
[ -e $USB ] && { BUSPOWER=$USB/buspower; break; }
done
echo 0x0 > $BUSPOWER
Para mim, parece que a parte usbhub / ethernet (essa é uma das principais diferenças para Pi3B) não obtém energia estável para um trabalho confiável (esse chip tem maior consumo de energia do que o chip usado no Pi3B)
mkreisl
em 24 mar. 2018
Obrigado - suas instruções parecem misericordiosamente curtas e simples. Como você disse, o lan78xx e seu driver parecem os culpados mais prováveis, mas não quero tirar conclusões precipitadas.
pelwell
em 24 mar. 2018
Obrigado - suas instruções parecem misericordiosamente curtas e simples. Como você disse, o lan78xx e seu driver parecem os culpados mais prováveis, mas não quero tirar conclusões precipitadas.
... e para executar o teste em loop não interativo, um script como este:
#!/bin/bash
for i in $(seq 1 10); do
logger running test $i
/usr/sbin/btrfs-auto-snapshot xbiancopy --helper --img /dev/root /srv/backup/test.img
done
Isso é o que estou executando no momento
mkreisl
em 25 mar. 2018
@pelwell @ JamesH65
é muito simples de reproduzir !!! montar um compartilhamento de rede, cole um vídeo e leia-o no compartilhamento. Você irá sistematicamente desconectar o vídeo após vários minutos de leitura ...
funciona também com uma cópia de um arquivo muito grande.
Knoppix1
em 25 mar. 2018
Aqui estão algumas perguntas para quem consegue reproduzir o problema:
Você consegue reproduzi-lo com o Raspbian?
Você tem um HDD externo conectado via USB durante o problema?
Qual sistema de arquivos é a base do servidor?
Há alguma modificação em cmdline.txt ou config.txt?
lategoodbye
em 25 mar. 2018
@lategoodbye
Sim, estou no Raspbian com firmware básico (4,9)
Novamente no HDD ou no armazenamento interno são as mesmas coisas.
Meu cmdline e configuração
$ cat /boot/cmdline.txt
dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=PARTUUID=8d333b2b-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait rootdelay=3
pi<strong i="9">@MyBilly</strong>:~ $ cat /boot/config.txt
# For more options and information see
# http://rpf.io/configtxt
# Some settings may impact device functionality. See link above for details
# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1
# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
#disable_overscan=1
# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16
# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720
# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1
# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1
# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2
# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4
# uncomment for composite PAL
#sdtv_mode=2
#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800
# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on
# Uncomment this to enable the lirc-rpi module
#dtoverlay=lirc-rpi
dtoverlay=pi3-disable-bt
dtoverlay=pi3-disable-wifi
# Additional overlays and parameters are documented /boot/overlays/README
# Enable audio (loads snd_bcm2835)
dtparam=audio=off
`
Aqui estão algumas perguntas para quem consegue reproduzir o problema:
Você consegue reproduzi-lo com o Raspbian?
Sim já postou
Você tem um HDD externo conectado via USB durante o problema?
Não / Sim, não importa
Qual sistema de arquivos é a base do servidor?
Não importa, compartilhamento cifs, nfs4 ou sshfs montado no servidor
Há alguma modificação em cmdline.txt ou config.txt?
Não
mkreisl
em 25 mar. 2018
Aqui estão algumas perguntas para quem consegue reproduzir o problema:
Você consegue reproduzi-lo com o Raspbian?
Sim ... Usando o Stretch mais recente.
Você tem um HDD externo conectado via USB durante o problema?
Sim, direto e por meio de um hub.
Qual sistema de arquivos é a base do servidor?
Sistema de arquivos em HD = NTFS. Sistema de arquivos ao conectar o PC = Windows 10 + Android.
Há alguma modificação em cmdline.txt ou config.txt?
Não, nem ... Tentei alguns MTUs diferentes sem nenhum efeito.
pjgpetecodes
em 25 mar. 2018
Não consigo reproduzir o problema com Raspbian (kernel 4.14.27) e meu RPI 3 B +. Ontem transferi a imagem Raspbian descompactada (~ 4 GB) via sftp e hoje via NFS. Sem problemas
lategoodbye
em 25 mar. 2018
E esse é o ponto crítico. Mas amanhã definiremos o problema com nossa equipe de engenheiros altamente treinados e esperamos fazer algum progresso.
pelwell
em 25 mar. 2018
Para referência, estou usando Samba ... Cartão exato funciona bem em um Pi 3 (Não B +) ... Mova para um B +, craps out depois de um GB / 1 minuto ou assim.
pjgpetecodes
em 25 mar. 2018
Sim, Samba ou Cifs muitas vezes parecem ser um elemento comum.
pelwell
em 25 mar. 2018
@mkreisl (nachteule?) Estou certo em pensar que a versão atual do Pi 2/3 XBian da página de downloads deve ser executada no 3B +? Números de versão e datas estão visivelmente ausentes.
pelwell
em 25 mar. 2018
@mkreisl (nachteule?) Estou certo em pensar que a versão atual do Pi 2/3 XBian da página de downloads deve ser executada no 3B +? Números de versão e datas estão visivelmente ausentes.
Sim, a versão mais recente suporta Pi3B +. Essa versão vem com o kernel 4.9.87+, se o kernel 4.14.29+ for desejado, o repositório de teste deve ser habilitado
mkreisl
em 25 mar. 2018
como corrigir isso permanecendo no firmware oficial?
Obrigado pela resposta
Knoppix1
em 28 mar. 2018
O kernel rpi-update mais recente tem algumas correções potenciais para kernel panics na rede. Você pode testar?
popcornmix
em 28 mar. 2018
Eu tropecei nisso.
Vou duplicar aqui o que postei nos fóruns.
Equipamento:
pi3b +
servidor ubuntu, i5 skylake, intel gigabit NIC
switch L2 gerenciado DLINK DGS-1210-10
Programas:
próprio sistema operacional GNU / Linux caseiro
kernel rpi-4.14.y @ https://github.com/raspberrypi/linux/commit/9d2ad143e40c38d34be86578840499a976c0a5b0
firmware mais recente no momento da escrita
Sintomas:
RX no pi3 muito pobre
TX bom
iperf3 -c rpi3plus -t 60 relata centenas de quedas, velocidade muito baixa (desculpe, não tenho números ruins em mãos)
O que eu tentei:
dtparam = eee = off: nenhuma alteração, pois eee já estava desabilitado em todas as portas do switch
forçar link para 100Mbit FD no switch: tudo bem, em velocidade de 100 mbit sem quedas, sem retrs em iperf3, velocidade de cópia de arquivo nfs é em torno de 95mbit / s
remova a velocidade de link forçada, habilite o controle de fluxo na porta 3b + no switch - BOM ,
iperf3 -c rpi3plus -t 60
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-60.00 sec 1.69 GBytes 242 Mbits/sec 8 sender
[ 4] 0.00-60.00 sec 1.69 GBytes 242 Mbits/sec receiver
dd if=/path/to/large/file/on/nfs4/mount/file.iso of=/dev/null iflag=direct bs=4M status=progress
5028970496 bytes (5.0 GB, 4.7 GiB) copied, 172 s, 29.2 MB/s
1200+1 records in
1200+1 records out
5035036672 bytes (5.0 GB, 4.7 GiB) copied, 172.307 s, 29.2 MB/s
md5-11642fa57d732b90ba82def1a215075a
ethtool -a eth0
Pause parameters for eth0:
Autonegotiate: on
RX: on
TX: on
RX negotiated: on
TX negotiated: on
Portanto, o controle de fluxo no switch resolve definitivamente a situação para mim.
Espero que isso forneça algumas pistas.
asavah
em 29 mar. 2018
A correção de corrupção 1ad1d52e6cb6a9fcee5d3fb08258b417ffda37fd parece muito interessante, não é necessário para rpi-4.14 também?
lategoodbye
em 29 mar. 2018
@asavah
ethtool -a eth0
Pause parameters for eth0:
Autonegotiate: on
RX: on
TX: on
RX negotiated: on
TX negotiated: on
Portanto, o controle de fluxo no switch resolve definitivamente a situação para mim.
Espero que isso forneça algumas pistas.
Se você não habilitar o controle de fluxo em seu switch, a saída do ethtool muda?
No meu bebê não gerenciado, os parâmetros de pausa do switch Netgear relatam negociação automática e ativados por padrão, então estou apenas tentando entender se é algo que normalmente esperamos estar ativado.
6by9
em 29 mar. 2018
@ 6by9
controle de fluxo desligado no interruptor:
root<strong i="7">@rpi3plus</strong>:~# ethtool -a eth0
Pause parameters for eth0:
Autonegotiate: on
RX: on
TX: on
RX negotiated: off
TX negotiated: off
EDIT: mais um pouco de teste com o FC desligado na chave:
ethtool -A eth0 tx off rx off
RUIM, ao copiar o arquivo com dd para / dev / null (veja o exemplo acima) a velocidade é ruim, o iftop relata picos de 2Mb / s
O próprio dd não responde a ctrl + c, o dmesg recebe spam com
[39643.040487] nfs: server nas2 not responding, still trying
[39643.040495] nfs: server nas2 not responding, still trying
Habilitou FC no switch e no pi3b + NIC e tudo está bom novamente.
Edit2: para fins de completude - nada está conectado às portas USB do pi, wi-fi é desabilitado via sobreposição.
PSU é RPF original.
asavah
em 29 mar. 2018
@asavah Obrigado, isso ajuda muito.
Os interruptores baby não gerenciados pelos quais fazemos a maioria dos nossos testes permitem o controle de fluxo por padrão. Switches gerenciados parecem não ter. Mudando para o envio de dados pelos principais switches gerenciados, vemos o problema.
Portanto, a questão é por que desativar o controle de fluxo do 802.3x é o padrão em switches gerenciados.
Não sou um especialista em redes, mas parece que sem ele o Pi terá problemas sem uma maneira real de contornar isso (estou assumindo que se o Pi enviar quadros de pausa quando o switch tiver desativado 802.3x, então eles estarão ignorado. @ JamesH65 está procurando ver se podemos enviá-los se não for negociado).
6by9
em 29 mar. 2018
Ainda não há respostas sobre se podemos substituir as configurações no driver, mas lendo sobre o assunto https://www.smallnetbuilder.com/lanwan/lanwan-features/30212-when-flow-control-is-not-a-good -coisa apresenta um caso para não querer o controle de fluxo. É o mesmo caso descrito em https://en.wikipedia.org/wiki/IEEE_802.3x#Issues , ambos discutindo a troca de envios de quadros de pausa devido ao preenchimento de FIFOs internos, nenhum dos dois discutindo o desejo do consumidor de pausar as transmissões .
6by9
em 29 mar. 2018
@lategoodbye Escolhi a dedo o commit de correção de corrupção para branches mais recentes.
Estou supondo que o commit não estará relacionado a problemas de controle de fluxo (mas pode evitar outros problemas).
popcornmix
em 29 mar. 2018
Outra descoberta na comparação de um Realtek r8152 com o lan78xx - os quadros jumbo parecem não estar habilitados no lan78xx, portanto, todos os quadros têm 1514 bytes.
Tentando decifrar o driver para o que precisa ser cutucado para habilitá-lo ...
6by9
em 29 mar. 2018
Portanto, a questão é por que desativar o controle de fluxo do 802.3x é o padrão em switches gerenciados.
Depende da marca.
Por exemplo, Juniper (popular em centros de dados) está ativado por padrão.
Ainda não há respostas sobre se podemos substituir as configurações no driver ainda
Experimente:
sudo ethtool --pause eth0 autoneg off
sudo ethrool -r eth0
Mas não contaria com seu switch aceitando os frames de pausa, se não habilitado.
maxnet
em 29 mar. 2018
@popcornmix Tentei fazer as mesmas transferências depois de atualizar com rpi-update, mas ainda tenho o mesmo problema, exceto agora, depois de falhar, dura mais tempo antes de falhar novamente. No passado, ele voltaria a falhar após um segundo ou mais após falhar pela primeira vez. Isso é o que o filezilla disse agora:
A transferência do arquivo falhou após a transferência de 4.342.120.448 bytes em 272 segundos
A transferência do arquivo falhou após a transferência de 3.275.915.264 bytes em 196 segundos
O problema, entretanto, é que agora, depois de falhar pela segunda vez, o filezilla não consegue retomar a transferência de arquivos e se desconecta do servidor, o que eu não tinha visto antes.
ltctceplrm
em 29 mar. 2018
O mesmo -_-
Knoppix1
em 30 mar. 2018
Olhando para a única página disponível sobre LAN7515 em microchip.com, me pergunto se Temp. Faixa máx. de 70 ° C não é um problema aqui. Alguém pode medir a temperatura do chip da LAN enquanto esse problema ocorre?
Comparado com o LAN9514, o novo LAN7515 tem:
Suporta 802.3az Engergy Efficient Efthernet
Suporta quadros jumbo de 9 KB
Oferece vários modos automáticos de economia de energia
Como podemos usar quadros jumbo?
Em um chip semelhante LAN7850, encontrei a seguinte nota :
Para evitar quedas de frame no RX FIFO ao usar frames jumbo com controle de fluxo, o
o tamanho máximo do quadro deve ser restrito a 4 KB ou menos.
fieryo
em 4 abr. 2018
Solicitamos informações sobre a ativação de quadros jumbo.
Para sua informação, minha produção 3B + compilou seu próprio kernel 6 vezes durante a noite em seu sistema de arquivamento montado em NFS sem problemas.
pelwell
em 4 abr. 2018
Os quadros Jumbo funcionam para mim.
Eles não são tão úteis para o usuário médio, no entanto, dado que, na prática, só funcionam em sua própria rede, seu switch precisa tê-los habilitados e você precisa definir o MTU mais alto ( ifconfig eth0 mtu <new mtu> ) em todos computadores com os quais você se comunica, não apenas no Pi.
O ganho de desempenho é mínimo.
MTU 1500 padrão:
pi<strong i="10">@raspberrypi</strong>:~ $ iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.178.26 port 5001 connected with 192.168.178.221 port 53742
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.1 sec 263 MBytes 219 Mbits/sec
[ 5] local 192.168.178.26 port 5001 connected with 192.168.178.221 port 53744
[ 5] 0.0-10.1 sec 263 MBytes 219 Mbits/sec
MTU 4000:
pi<strong i="14">@raspberrypi</strong>:~ $ iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.178.26 port 5001 connected with 192.168.178.221 port 53758
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 271 MBytes 227 Mbits/sec
[ 5] local 192.168.178.26 port 5001 connected with 192.168.178.221 port 53760
[ 5] 0.0-10.0 sec 272 MBytes 227 Mbits/sec
Pode verificar, olhando para ethtool -S eth0 quadros jumbo foram recebidos:
RX Greater 1518 Byte Frames: 279374
==
Duas outras notas:
Se há problemas de desempenho quando o controle de fluxo é desabilitado, parece depender de outros fatores também.
Eu vejo o problema em um HP 1810G, mas em um TP-link TL-SG108E V3 ele funciona bem mesmo com o controle de fluxo desabilitado (e sim, verifiquei que estava realmente desligado com o ethtool)Não vejo o problema de travamento de conexão descrito neste tópico com muita freqüência, mas quando vejo, há outros problemas com o sistema também.
Por exemplo, todo o sistema travou ao transferir um lote uma vez.
E parece que houve corrupção de memória ou o relógio do sistema foi danificado em outro momento.
Disse ao meu computador normal para transferir dados por uma hora para o Pi. E olhando para a baixa velocidade de transferência, acho que parou no meio do caminho:
max<strong i="32">@lynx</strong>:~$ iperf -c raspberrypi.local -t 3600
------------------------------------------------------------
Client connecting to raspberrypi.local, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.178.221 port 38764 connected with 192.168.178.26 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-3600.1 sec 49.4 GBytes 118 Mbits/sec
O Pi, entretanto, pensou que estava recebendo dados por vários dias, observando o número de segundos no "intervalo".
pi<strong i="36">@raspberrypi</strong>:~$ iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.178.26 port 5001 connected with 192.168.178.221 port 38764
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-241884.4 sec 49.4 GBytes 1.76 Mbits/sec
Isso parece mais um problema de driver / software do que algo que pode ser atribuído a mim pelo hardware da LAN.
maxnet
em 4 abr. 2018
É uma interação engraçada entre o chip da LAN, o driver e outra infraestrutura da LAN. Muitas variáveis que precisam ser reduzidas.
A conclusão mais provável é que o controle de fluxo será obrigatório para uma operação de gigabit confiável e não parece haver uma maneira garantida de o Pi forçá-lo.
Os quadros Jumbo parecem ser uma pista falsa. O adaptador baseado em Realtek RTL8153 que testamos (usa o driver r8152) parece ter um certo nível de descarregamento de rede que combina os quadros TCP de entrada antes de entregá-los na pilha. O Wireshark rodando no Pi, portanto, vê pacotes grandes, mas rodando em uma porta espelhada do switch confirma que em um nível de fio eles têm o comprimento normal de 1516 bytes.
O teste com um adaptador baseado em AX88179 fornece resultados muito semelhantes aos do chip LAN integrado.
Acontece que eu tinha um TP-link TL-SG108E V3 em casa, então é com isso que estamos testando - ele está mostrando uma diferença significativa com o controle de fluxo ligado ou desligado. Confirmaremos os resultados novamente mais tarde na Netgears corporativa.
6by9
em 4 abr. 2018
Acontece que eu tinha um TP-link TL-SG108E V3 em casa, então é com isso que estamos testando - ele está mostrando uma diferença significativa com o controle de fluxo ligado ou desligado.
Hmm, você está certo.
Cometi o erro de testar apenas dentro da rede.
E internamente a velocidade está ok com essa chave, mesmo sem controle de fluxo. Presumivelmente porque não há lag e o outro computador é capaz de reenviar os pacotes perdidos rapidamente.
pi<strong i="10">@raspberrypi</strong>:~$ ethtool -a eth0
Pause parameters for eth0:
Autonegotiate: on
RX: on
TX: on
RX negotiated: off
TX negotiated: off
pi<strong i="11">@raspberrypi</strong>:~$ iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.178.26 port 5001 connected with 192.168.178.221 port 55952
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 267 MBytes 224 Mbits/sec
Mas quando o teste em relação a um servidor remoto, a velocidade de download é realmente ruim quando o controle de fluxo está desligado:
pi<strong i="15">@raspberrypi</strong>:~$ speedtest-cli
Retrieving speedtest.net configuration...
Testing from Ziggo (*.*.*.*)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Qweb | Full-Service Hosting (Alblasserdam) [34.63 km]: 20.12 ms
Testing download speed................................................................................
Download: 62.73 Mbit/s
Testing upload speed....................................................................................................
Upload: 25.09 Mbit/s
vs com controle de fluxo:
pi<strong i="19">@raspberrypi</strong>:~$ speedtest-cli
Retrieving speedtest.net configuration...
Testing from Ziggo (*.*.*.*)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by KPN B.V. (Den Haag) [2.03 km]: 16.444 ms
Testing download speed................................................................................
Download: 198.96 Mbit/s
Testing upload speed....................................................................................................
Upload: 25.79 Mbit/s
perdoe minha ignorância. Eu tenho um problema que está descrito aqui. Não sei sobre programação, codificação, scripts. Defini RPi3B + graças aos guias. Posso corrigir o erro de alguma forma? Eu ainda tenho que esperar por uma correção? RPi3b funcionou muito bem, a versão mais recente, infelizmente não.
frrancuz
em 28 abr. 2018
Ainda parece não haver um ATM consertado. Solução alternativa para mim é transferir algum arquivo grande (> 1 GB) por SFTP - falha algumas vezes, mas as transferências do Samba funcionam novamente por algum tempo. Portanto, não há mais necessidade de reiniciar para mim. Quando eu preciso atualizar meu Arch Linux do meu repositório local no PI sobre HTTP, eu tenho que também executar a transferência SFTP paralela, caso contrário, não funcionaria, ainda falha algumas vezes, mas muito menos.
Otw-cz
em 28 abr. 2018
Devo dizer que https://github.com/raspberrypi/linux/commit/354898f0a0f4a62ab950e826c8c598fc78378b06 melhora minha experiência com o kodi. Antes, ele travava a reprodução 1 n vezes a cada reprodução de vídeo.
stevenhoving
em 5 mai. 2018
Eu também tive um problema semelhante no 3B + quando uso o Plex Media Server e quando uso o SCP. Ele para aleatoriamente e vejo muitos pacotes presos em Send-Q quando digito netstat -an .
No entanto, quando substituo o cabo Ethernet de CAT5e para CAT6 , ele resolveu dramaticamente em meu ambiente. Eu nunca encontro o travamento quando o SCP e o Plex Media Server são iguais ao meu antigo 3B.
hidetosaito
em 12 mai. 2018
Oh legal !
Exatamente na mesma situação com o plex! meu cabo é cat5e
Vou testar durante o dia.
Knoppix1
em 13 mai. 2018
Apenas para registro, eu estava enfrentando o mesmo problema com o OSMC no 3B +. Originalmente, pensei que estava relacionado ao NTFS no SSD externo, mas no meu último teste também fui capaz de reproduzi-lo na partição ext4.
A história original está aqui: https://discourse.osmc.tv/t/sftp-stalls-when-transferring-files-from-ntfs-drive/72526
Versão TL; DR: Ao transferir arquivos do SSD que está conectado ao RPi via ponte USB / SATA, usando SFTP a transmissão para depois de um tempo.
O que não foi mencionado neste tópico, mas o que observei com o Filezilla, que tenta se reconectar automaticamente após um tempo limite, foi que após a reconexão a transferência continuou por uma fração de segundo, antes de travar novamente. Como se encerrar a conexão e criar uma nova liberasse alguns recursos, antes de travar novamente.
risa2000
em 15 mai. 2018
Oi, pessoal,
Você tem alguma solução / solução alternativa para isso? Acho que muitas pessoas estão enfrentando esse problema, mas como esse problema é muito difícil de identificar corretamente, as pessoas estão culpando todo tipo de coisa (samba, nfs, NTFS, sftp, etc). Acha que devo devolver o produto ao vendedor ou aguardar uma solução?
Obrigada.
rfpaiva
em 4 jun. 2018
Você verificou se há controle de fluxo em sua rede?
Você fez um rpi-update para garantir que possui o kernel e os patches mais recentes?
JamesH65
em 4 jun. 2018
O controle de fluxo não está presente na minha rede, verificado várias vezes e também testei com diferentes roteadores.
Eu executei o rpi-update ontem e, à primeira vista, o erro não está mais lá. Vou fazer mais alguns testes pesados hoje e retorno para você.
Eu executei o rpi-update algumas semanas atrás e ele não resolveu o problema, então presumo que uma nova versão tenha sido lançada nesse meio tempo.
Obrigado novamente.
rfpaiva
em 5 jun. 2018
Talvez isso esteja relacionado aos travamentos de conexão:
https://marc.info/?l=linux-arm-kernel&m=152828525609642&w=2
lategoodbye
em 6 jun. 2018
Estive examinando isso novamente, transferindo arquivos grandes de um dispositivo USB no Pi para um laptop Windows via Samba. Nenhum problema visto até agora com o kernel mais recente (4.14.44) após 10 GB. Vou continuar fazendo os testes.
@lategoodbye Esse é um link interessante. Não tenho certeza se é relevante, mas certamente parece possível.
JamesH65
em 6 jun. 2018
É melhor pousada 4.14.44 ... mas depois de 1 dia pareço um problema. Com plex e samba share.
Acabei de atualizar 4.14.48 estou esperando para ver ..
Knoppix1
em 7 jun. 2018
Estou curioso para saber se a desativação da troca tem alguma influência sobre este problema:
sudo swapoff -a
lategoodbye
em 7 jun. 2018
Estou curioso para saber se a desativação da troca tem alguma influência sobre este problema
Também vi o problema sem troca.
(Eu e outros usuários do Berryboot não trocamos, já que o dphys-swapfile não funciona em sistemas de arquivos aufs em camadas)
maxnet
em 7 jun. 2018
Também estou tendo esse problema no meu Pi3b + que peguei há 2 semanas no CanaKit.
Eu atualizei para o kernel mais recente (4.14.48) hoje e ainda estou tendo esse problema. Grandes transferências de um HDD conectado ao Pi3b + travam com um erro após alguns minutos. Além disso, quando estou assistindo a arquivos de vídeo armazenados em um disco rígido conectado ao pi3b + do meu laptop ou outro pi no samba, o vídeo trava, e foi assim que descobri o problema pela primeira vez.
joickle
em 7 jun. 2018
Desativar a troca não corrige o problema de transferência. Nem a atualização rpi de hoje 4.14.48. (Testado em HTTP e SAMBA)
Otw-cz
em 7 jun. 2018
@joickle Bit incerto, você está vendo o problema sem usar a Ethernet? Apenas reproduzindo de um HD conectado no próprio Pi? Existe alguma mensagem de erro no syslog? Ou é apenas via Samba?
Como acima, tentei fazer isso e não consegui replicar, então não sei como proceder.
JamesH65
em 8 jun. 2018
Depois de mais alguns testes, mantendo o PI ligado por um bom período de tempo, percebi que as transferências de arquivos estão mais estáveis, mas o problema está definitivamente aí. A transferência de arquivos falha, a conexão é perdida. Em alguns casos, não consigo nem iniciar uma nova transferência, o processo continua tentando copiar, mas não há atividade de rede, como uma situação de deadlock. O comando ping nunca falha. Após a reinicialização, as transferências de arquivos funcionam novamente e falham depois de um tempo.
rfpaiva
em 8 jun. 2018
@ JamesH65
Como acima, tentei fazer isso e não consegui replicar, então não sei como proceder.
Desde que você esteja apenas executando procedimentos de cópia simples para reproduzir o problema, você nunca será capaz de reproduzir este problema, então você tem que trabalhar um pouco mais
Boas amostras você pode encontrar aqui
mkreisl
em 8 jun. 2018
Como você sabe? Alguma ideia de POR QUE cópias simples funcionam, mas 'outra coisa' não? Simplesmente dizer nunca em negrito é tão útil quanto um bule de chocolate sem algum tipo de raciocínio por trás disso.
Eu também tentei streaming, e PODE ter reproduzido algo uma vez, mas apenas uma vez. Nenhuma mensagem de log, a máquina podia executar o ping, outros compartilhamentos do samba ainda estavam funcionando. A única prova era que o link parecia ter sido descartado.
JamesH65
em 8 jun. 2018
@ JamesH65 Estou executando o pi3b + como NAS e estou usando samba sobre ethernet. O problema aparece ao transferir arquivos de vídeo muito grandes do pi3b + para o meu laptop ou quando estou transmitindo arquivos de vídeo do pi3b +.
Se você estiver apenas ligando o pi e testando, provavelmente terá sucesso, como outros mencionaram, está tudo bem por uma ou 2 horas após a reinicialização, então começa a acontecer novamente.
joickle
em 8 jun. 2018
@ JamesH65 Exatamente :-) Sem mensagens log / dmesg, sem erros ethtool -S, ping / máquina funciona, mas a conexão trava e, eventualmente, é encerrada, geralmente não pode ser retomada imediatamente, leva algumas tentativas, mas é instável, ou reinicie ou " Solução alternativa SFTP descrita anteriormente "após a qual funciona novamente por algum tempo. Copiar pode ser tão rápido que esse erro não ocorre. Isso acontece sempre durante o streaming, mas pode funcionar uma hora ou mais antes de travar e ser aleatório. (Estou executando o PI 24/7 como servidor de arquivos e tal ...)
Otw-cz
em 8 jun. 2018
Estou certo de que o problema requer um switch gerenciado para ser reproduzido?
lategoodbye
em 8 jun. 2018
Estou conectado via ethernet a um roteador Asus RT-N66U, tenho certeza que o problema não é o roteador, pois funcionou perfeitamente em um servidor pi2 e ubuntu.
joickle
em 8 jun. 2018
@lategoodbye FWIW, eu fiz o teste A / B usando RPi 3b e RPi 3b + exatamente no mesmo ambiente (usando TP-LINK TP-WR1043NDv2 executando OpenWRT / LEDE no meio, RPi em um lado, desktop com Win 7 no outro ) e executando o mesmo sistema operacional (OSMC mais recente usando o mesmo cartão SD). RPi 3b não exibiu o problema (mas obviamente estava funcionando na metade da velocidade de RPi 3b +), RPi 3b + sim.
risa2000
em 8 jun. 2018
@ JamesH65
Como você sabe? Alguma ideia de POR QUE cópias simples funcionam, mas 'outra coisa' não? Simplesmente dizer nunca em negrito é tão útil quanto um bule de chocolate sem algum tipo de raciocínio por trás disso.
Porque eu sei disso. Quando eu estava começando com Pi3B +, essas transferências de arquivos simples e estúpidas sempre funcionavam, quanto mais dados vão bidirecionais por usb, maior a probabilidade de que o problema ocorra
Passei muito tempo com esse f ...... problema de rede, então sei o que estou lendo. Ofereci minha ajuda há algumas semanas, enviei um PM no fórum para vocês, por outro lado estava pedindo suporte de hardware para a execução de mais testes, mas tudo que recebi foi uma resposta não relacionada à minha dúvida de sua parte. É por isso que o tópico foi feito para mim. E parece que você e todos os outros caras @ RPF ainda não têm absolutamente nenhuma ideia do que está acontecendo lá e como resolver isso.
Eu também tentei streaming, e PODE ter reproduzido algo uma vez, mas apenas uma vez. Nenhuma mensagem de log, a máquina podia executar o ping, outros compartilhamentos do samba ainda estavam funcionando. A única prova era que o link parecia ter sido descartado.
Sim, como já disse, você tem que construir um cenário mais complexo.
mkreisl
em 8 jun. 2018
@mkreisel @ JamesH65 Acho que podemos precisar ser mais específicos. Me deparei com esse problema ao fazer transferências SFTP da partição NTFS em um disco externo conectado ao RPi 3b +. Eu chamaria essas transferências de "simples" no meu livro, mas elas pararam de qualquer maneira. Tive muito mais sucesso com a partição ext4 na mesma unidade, mas eventualmente consegui interromper a transferência SFTP desta também (conforme descrito aqui: https://discourse.osmc.tv/t/sftp-stalls-when-transferring -files-from-ntfs-drive / 72526).
Eu tentei depurá-lo ativando a depuração no NTFS e no SFTP, mas não mostrei nada de extraordinário, nem dmesg ou journalctl. No final, a conexão simplesmente para. Como também observei acima, reiniciar a conexão no nível SFTP (reconexão automática no FileZilla) conseguiu fazer mais alguns bytes antes de travar novamente.
Se você está procurando maneiras de reproduzir esse problema, acho que minha configuração é o mais simples possível. Basta anexar uma unidade externa (estou usando o Samsung EVO 850), formatar para NTFS e executar transferências SFTP do RPi. Use arquivos grandes para o teste de vários GB. Depois de várias transferências e algum tempo após a inicialização (parece também estar relacionado ao tempo de atividade), você deve acertá-lo.
risa2000
em 8 jun. 2018
@joickle @ risa2000 Você não entendeu minha pergunta, eu nunca disse que seu switch / roteador está quebrado. Substituir o RPI 3 B + por um RPI 3B não fornece novas informações porque eles usam um driver de rede diferente e a chance é muito alta de que o problema esteja no driver (ou pelo menos conectado). Contanto que não tenhamos uma configuração de teste definida, corrigir esse problema é impossível.
lategoodbye
em 8 jun. 2018
@mkreisl Você pode dizer que é necessário um cenário mais complexo, mas outros não.
O pôster original é transmitido apenas do Pi, e outros dizem que eles estão apenas transmitindo do Pi.
Você também se contradisse ao relatar inicialmente que tudo estava bem na WLAN e depois dizer que não. Confunde um pouco as águas: - / Estamos olhando para um problema de Samba (exceto algumas pessoas dizem que NFS também), um problema de LAN78xx ou um Pi duvidoso?
Obter uma imagem coesa não é fácil, o que torna significativamente mais difícil chegar ao fundo do problema.
Algumas perguntas para qualquer pessoa com problemas, principalmente para tentar restringir as condições necessárias. ("Toos" aleatórios sem quaisquer detalhes não são terrivelmente úteis).
- mudar para 100baseT funciona?
ethtool -s eth0 autoneg offethtool -s eth0 speed 100(asavah relatou que corrigiu os problemas para ele, mskreisl relata que não) - Esse controle de fluxo é ativado se estiver executando como 1000baseT.
ethtool -a eth0deve relatar "ativado" em todos os campos. - as pessoas podem confirmar se NÃO estão executando VLANs.
- IPv4 ou IPv6? Afeta o descarregamento do adaptador (sim mskreisl, eu vi que você relatou que seu caso parece funcionar em IPv6 e não em IPv4. Seria útil para outras pessoas confirmarem isso em suas configurações. IPv4 é nossa configuração normal e nós não reproduzindo o problema)
- é corrigido se o descarregamento está desativado? Precisa ser para tx e rx?
sudo ethtool -K eth0 rx offesudo ethtool -K eth0 tx off(sudo ethtool -k eth0para ver o status). - onde os indivíduos tiveram problemas em uma placa 3B +, se possível, teste em outra placa 3B +. É possível que uma placa específica esteja com defeito / intermitente.
- onde as pessoas estão transferindo dados do Pi, qual é o dispositivo de origem? SDcard, USB HDD, USB SSD ou algo mais?
Isso não está sendo ignorado, mas não ser capaz de reproduzi-lo atrapalha o progresso.
6by9
em 8 jun. 2018
Se ajudar, meu pi3b + está rodando o último raspbian stretch lite, com 2 HDDs USB conectados através de gabinetes externos, cada um tem sua própria fonte de alimentação e partições NTFS rodando. Estou usando o samba para disponibilizar as unidades na rede. A única vez que tenho esse problema é quando transfiro vários arquivos de vídeo muito grandes (1 GB + cada) do pi para o meu pc com Windows. Também acontece quando estou transmitindo os arquivos de vídeo dos discos rígidos USB do pi3b +, o vídeo bloqueia aleatoriamente.
Além disso, está tudo bem após uma reinicialização e leva pelo menos uma hora ou mais antes de aparecer novamente.
joickle
em 8 jun. 2018
@ 6by9 Não tive tempo de fazer testes mais profundos,
a situação atual para mim (com o kernel construído ontem do branch rpi-4.14.y) é:
- habilitar o controle de fluxo no switch gerenciado não salva mais a situação (nfs timeouts e etc), eu preciso testar isso novamente (farei no fim de semana se possível), é por isso que mudei para 100 Mbit
- forçando o link para 100Mbit no lado do switch - tudo bem, assim como 3b (sem mais), o uso principal _heavy_ lan é nfs v4, udp, o outro lado é o servidor skylake 1gbit
asavah
em 8 jun. 2018
No OSMC, notamos que esses problemas são mais prevalentes ao usar o Samba. O problema é particularmente perceptível ao usar sistemas de arquivos baseados em FUSE. Parece que os clientes Windows parecem fazer duas solicitações: uma para obter um ETA para transferência e outra para executar a operação solicitada. Isso faz com que sistemas de arquivos baseados em FUSE como exFAT e NTFS caiam. Parece exacerbado> 100 Mbps.
@ risa2000 Ainda não disponibilizei as alterações mais recentes, mas farei isso nos próximos dias.
samnazarko
em 8 jun. 2018
descobri que hoje vou tentar amanhã para ver se isso corrige o problema como uma solução
Rode isto
ethtool --offload eth0 rx off tx desligado
Mudanças reais:
rx-checksumming: off
tx-checksumming: off
tx-checksum-ip-generic: off
tcp-segmentation-offload: off
tx-tcp-segmentation: off [solicitado em]
segmentação tx-tcp6: off [solicitado em]
Eu encontrei isso aqui e parece resolver esse problema
https://www.raspberrypi.org/forums/viewtopic.php?t=209258
Tive que reverter para um pi3 por causa disso para o meu servidor de mídia
Bignumbas
em 10 jun. 2018
@Bignumbas É idêntico a ethtool -K eth0 rx off e ethtool -K eth0 tx off que pedi às pessoas para experimentarem em https://github.com/raspberrypi/linux/issues/2449#issuecomment -395819097. No entanto, eu também solicitei informações sobre se precisa ser nas duas direções - alguma entrada aí?
O descarregamento da soma de verificação é um candidato potencial para problemas, mas desativá-lo sem uma compreensão de onde o problema não é uma solução geral sensata. Para começar, ele está desativando várias funções de descarga diferentes, então que tal dirigir seu carro apenas na primeira marcha porque você sabe que há um problema nas marchas mais altas, mas não descobriu qual delas é o problema.
6by9
em 10 jun. 2018
@ 6by9 Eu testei isso, mas queria ter certeza de que está funcionando um pouco antes de relatar. Eu também usei ethtool --offload eth0 rx off tx off e até agora tem funcionado muito bem, sem travamentos ou transferências com falha. No entanto, quando eu uso este comando, ele retorna um erro parcial.
O ethtool -K eth0 rx off retorna um erro de operação não suportada:
Cannot get device udp-fragmentation-offload settings: Operation not supported
Cannot get device udp-fragmentation-offload settings: Operation not supported
e ethtool -K eth0 tx off retorna:
Cannot get device udp-fragmentation-offload settings: Operation not supported
Cannot get device udp-fragmentation-offload settings: Operation not supported
Actual changes:
tx-checksumming: off
tx-checksum-ip-generic: off
tcp-segmentation-offload: off
tx-tcp-segmentation: off [requested on]
tx-tcp6-segmentation: off [requested on]
Até agora, isso está funcionando muito bem, mas adoraria ver uma solução real em breve.
joickle
em 10 jun. 2018
@joickle Por favor, tente UM DE ethtool -K eth0 tx off OU ethtool -K eth0 rx off . Algum deles resolve o problema? Se sim, qual?
Se possível, analise qual subopção está causando problemas.
Confirme também se você está executando IPv4 ou IPv6 - como você pode ver na saída, existem diferentes opções de descarregamento entre os dois.
Só estou me perguntando se a Microchip não corrigiu o problema que eles tinham no SMSC95xx - https://github.com/raspberrypi/linux/commit/fe0cd8ca1b82983db24b173bb8518ea646c02d25#diff -c1b6c5470b2ae917eb5e620b19c1aa63. No entanto, isso seria apenas IPv6, o que parece não ser o caso aqui.
6by9
em 10 jun. 2018
@ 6by9 Ok, vou tentar cada um individualmente e relatar de volta. No entanto, parece que o rx não faz nenhuma alteração, pois apenas retorna os erros de operação não suportada.
Também estou executando o IPv4, o IPv6 está desabilitado no meu roteador.
Edit: Devo também mencionar que voltei para a versão oficial 4.14.34 também.
joickle
em 10 jun. 2018
Obrigada.
Não confio nos resultados de configurar coisas no ethtool - ele relata os erros de sub-alterações, mas nem sempre as alterações. O driver é compatível com o descarregamento de soma de verificação rx.
4.14.34 inclui todas as alterações que fizemos em torno da filtragem de VLAN e soma de verificação, portanto, não deve haver nenhuma alteração faltando nisso.
Suspeito que teremos que escrever um aplicativo de teste que envie pacotes UDP incrementais para exercitar todos os valores da soma de verificação e validar se todos eles foram recebidos na extremidade oposta.
Suponho que ninguém tenha uma captura do WireChark da rede quando isso der errado?
6by9
em 10 jun. 2018
@ 6by9 , parece que sudo ethtool -K eth0 tx off sozinho é o ovo de ouro que permite que as transferências e fluxos do pi sejam concluídos.
Eu nunca tinha ouvido falar de WireShark até agora, como posso tentar conseguir uma captura para você?
joickle
em 10 jun. 2018
Muito Obrigado.
Ainda temos o problema de não sermos capazes de replicar, então se você puder isolar qual dos recursos de transferência de tx está causando o problema, isso seria brilhante.
Ative tudo novamente (tx ativado) e, em seguida, tente cada uma das seguintes opções, reativando-as antes de prosseguir:
sudo ethtool -K eth0 tx-checksum-ipv4 off
sudo ethtool -K eth0 tx-checksum-ip-generic off
sudo ethtool -K eth0 tx-tcp-segmentation off
(desculpas se entendi errado - só tenho um B disponível)
Segure o controle de execução do wirehark por enquanto, pois não tenho certeza de qual extremidade realmente precisa ser capturada.
Para mais informações: sudo apt install wireshark . Geralmente eu não me preocupo com usuários não root executando o WireShark. Use sudo wireshark para executá-lo (é um aplicativo GUI). Selecione a interface de rede relevante e ela iniciará a captura. É provável que o problema seja que, se você estiver apenas transmitindo em geral, isso consumirá uma grande quantidade de memória / disco, então pode não ser prático de fazer.
6by9
em 10 jun. 2018
dumpcap (parte do pacote tshark ) pode ser configurado para usar um anel de buffers de tamanho fixo:
sudo dumpcap -i eth0 -w <file.cap> -b filesize:32768 -b files:128
Isso lhe dará 128 arquivos de 32 MB cada, para um total de 4 GB de gravação. Com um pouco de sorte, o travamento da rede efetivamente pausará a captura e deixará um registro utilizável.
pelwell
em 10 jun. 2018
Ah, obrigado @pelwell. Eu sabia que devia haver uma opção no tcpdump ou similar, mas não iria caçar agora.
Pensando nisso, visto que está descarregando a transmissão terá que estar no dispositivo receptor, ou outro dispositivo na rede (problemas de interruptores e necessidade de modos de monitor).
Dito isso, novas tentativas podem aparecer em determinados pacotes de saída (imediatamente antes de a sessão ser encerrada).
6by9
em 10 jun. 2018
Parece que 2 de 3 têm um resultado positivo, testado duas vezes para ter certeza.
sudo ethtool -K eth0 tx-checksum-ip-generic off
sudo ethtool -K eth0 tx-tcp-segmentation off
Meu pi está executando o raspbian lite sem cabeça, então acho que não posso fazer a captura do wirehark de qualquer maneira.
joickle
em 10 jun. 2018
Tanto o dumpcap quanto o tshark são utilitários de linha de comando, portanto, facilmente executados em SSH.
pelwell
em 10 jun. 2018
Do relatório de @joickle de 2 comandos com resultado positivo (que estou lendo "positivo" como "não estou vendo problemas"), acho que possivelmente temos uma arma em chamas em tx-tcp-segmentation (não é definitivo o suficiente para estar fumando!).
Testando os comandos sozinho em um 3B +
pi<strong i="9">@raspberrypi</strong>:~ $ sudo ethtool -K eth0 tx-checksum-ip-generic off
Cannot get device udp-fragmentation-offload settings: Operation not supported
Cannot get device udp-fragmentation-offload settings: Operation not supported
Actual changes:
tx-checksumming: off
tx-checksum-ip-generic: off
tcp-segmentation-offload: off
tx-tcp-segmentation: off [requested on]
tx-tcp6-segmentation: off [requested on]
ou seja, desabilitar tx-checksum-ip-generic também desabilita a segmentação.
Desabilitar apenas tx-tcp-segmentation apenas ajusta uma configuração e deixa tx-checksum-ip-generic habilitado, o que implicaria que as somas de verificação estão OK.
Terei uma leitura sobre exatamente o que o descarregamento de segmentação está fazendo (a teoria pode ser diferente da prática).
6by9
em 11 jun. 2018
@ 6by9 Também notei isso. Eu deixei tx-tcp-segmentation fora e até agora sem problemas desde então :)
joickle
em 11 jun. 2018
Só para constar, fiz alguns testes bastante simples e não particularmente refinados, e não pude ver nenhuma degradação de desempenho seja na velocidade de transferência ou no uso da CPU ao ativar e desativar essas configurações, ao usar o Pi para servir um Samba compartilhado. Usei um laptop Win10 rápido para se conectar ao compartilhamento e copiar um arquivo de 4 GB do Pi para a pasta local. Os dados no Pi foram armazenados em um cartão SD exfat em um adaptador USB, então o sistema estava exercitando o barramento USB para Ethernet e o dispositivo USB. A velocidade de transferência média aproximada foi de 16,5 MB / s (132 Mbits / s). Dado que o barramento USB está sendo usado duas vezes (ethernet e adaptador USB), podemos dobrar para 264 ou mais, pouco mais da metade do máximo teórico do USB (480), o que, dados os habituais overheads de USB, parece estar certo.
JamesH65
em 11 jun. 2018
Essa é uma informação útil - obrigado pela atualização.
Para informações, a segmentação tcp permite que o sistema operacional envie um grande pacote TCP para o adaptador de LAN, e o adaptador de LAN então o divide em pedaços de tamanho MTU / MSS apropriados, incluindo o preenchimento da soma de verificação do cabeçalho TCP e dos campos de número de sequência do cabeçalho. Isso explica por que executar uma captura de pacote no lado da transmissão frequentemente resultará em ver pacotes impossivelmente grandes sendo enviados em interfaces Ethernet.
A lógica também segue que, se o adaptador não estiver fazendo os cálculos da soma de verificação, ele não poderá fazer a segmentação, portanto, desabilitar a soma de verificação também deve desabilitar a segmentação.
Tentar identificar o que está errado com a segmentação tcp é a próxima etapa, mas isso deixa um grande número de causas potenciais.
Pensamento muito maluco: o descarregamento de segmentação TCP está recalculando o número de sequência TCP dos pacotes (quantos bytes até agora foram enviados pela sessão TCP). Isso é um valor de 32 bits, então vai mudar para 0 em 2 ^ 32-1 ou 4GB-1. O mecanismo de descarregamento lida corretamente com esse envoltório? Do contrário, as coisas morreriam em torno da marca de 4 GB.
Se a transferência estiver sendo executada a 250 Mbit / s (possivelmente um pouco otimista), o envio de 4 GB de dados brutos levaria 137 segundos, e as pessoas estão dizendo que houve falhas após alguns minutos.
Testes chegando ....
6by9
em 11 jun. 2018
@ JamesH65
Pi3B + (Stretch), HDD externo (exFAT), Samba, todos com as últimas atualizações. LAN de 1 GB, Win10-PC.
A cópia do Pi para o PC funciona bem (quase sempre) com 1 GB por minuto (o tamanho do arquivo é de cerca de 1,5 GB).
A cópia do PC para o Pi funciona apenas com 100 MB - travando principalmente.
A cópia do Pi para o PC trava ao iniciar um PC para a cópia do Pi ao mesmo tempo.
Copiar HDD para SD interno (sem LAN) funciona com 1 GB - SD para HDD novamente lento com 100 MB.
Cópia interna em ambas as direções - com falha total.
NorbertM21
em 11 jun. 2018
@ NorbertM21 Você fez o seguinte na linha de comando Pi antes de executar os testes?
sudo ethtool -K eth0 tx-tcp-segmentation off
JamesH65
em 11 jun. 2018
@ NorbertM21 Além disso, o que você quer dizer com uma cópia interna?
Também parece que você pode ter o controle de fluxo desligado em sua rede
JamesH65
em 11 jun. 2018
System-SD para USB-HDD, sem transferência via Ethernet para um PC ou Mac (o que causa os mesmos problemas).
NorbertM21
em 11 jun. 2018
@ NorbertM21 Você consegue travar mesmo quando não está copiando pela rede, apenas para um HDD conectado por USB? Em caso afirmativo, acho que você está vendo um problema diferente. O problema descrito aqui é ao usar a rede.
JamesH65
em 11 jun. 2018
Também tenho esses problemas ao copiar Pi para o PC e de PC para o Pi.
A cópia interna era apenas para teste.
Na minha configuração, não encontro nenhuma opção para definir FlowControl - Fritz! Box 7270 100mBit LAN e GB-Switches passivos normais. O adaptador de rede do PC está com o FlowControl ativado.
NorbertM21
em 11 jun. 2018
O mecanismo de descarregamento lida corretamente com esse envoltório? Do contrário, as coisas morreriam em torno da marca de 4 GB.
Reivindicação parcial da pilha. O número de sequência inicial do TCP é escolhido aleatoriamente, portanto, estatisticamente, ele poderia ser escolhido como (2 ^ 32) -1 e cairia imediatamente. Como isso geralmente não é visto, não pode ser totalmente fatal. As investigações continuam.
6by9
em 11 jun. 2018
@ 6by9 para mim quando estava testando essas configurações ontem, uma vez que começasse a falhar, falharia imediatamente nas novas tentativas até desligar a segmentação tcp. Desativar a segmentação tcp permite que as transferências sejam realizadas sem a necessidade de reinicialização.
joickle
em 11 jun. 2018
@joickle Curioso, pois eu esperava que qualquer problema de segmentação
Em uma estranheza que @ JamesH65 e eu netstat -na ), mas o Windows ainda estava tentando usá-lo. Mude para outro dispositivo e faça um Samba, SSH ou outra conexão e o Pi ainda estará funcionando. Basicamente, o Windows precisava ser chutado para encerrar a sessão de Samba morta e tudo estava certo com o mundo novamente.
Eu me pergunto se o seu é um problema semelhante em que o Windows precisa ser chutado de forma adequada.
Agora estou curioso para saber se a desativação do descarregamento de segmentação tcp funciona para @asavah em 1000baseT. Você também pode confirmar se está executando NFS sobre TCP ou UDP? Se UDP, então isso só me chocou, pois a segmentação só afetará o TCP.
6by9
em 11 jun. 2018
@ 6by9
Desculpe por enganá-lo em uma postagem anterior, https://github.com/raspberrypi/linux/issues/2449#issuecomment -395820912
Eu estava realmente usando NFSv4 _tcp_ quando percebi o problema, mesmo com o controle de fluxo habilitado.
Eu estava fazendo testes e fui interrompido, então esqueci o que estava fazendo e em que ordem,
então esqueci completamente que também estava brincando com opções de nfs no fstab.
Reinicializou o sistema entre cada teste
opções NFS atuais no cliente conforme relatado por mount
nas2:/media/nas on /media/nas type nfs4 (rw,noatime,nodiratime,vers=4.2,rsize=32768,wsize=32768,namlen=255,hard,nocto,proto=tcp,timeo=14,retrans=2,sec=sys,clientaddr=192.168.36.111,local_lock=none,addr=192.168.36.5)
BOA
1 Gbit
Flowcontrol "ligado" no interruptor
descarregamento de segmentação tcp desligado
nfs v4 _tcp_
uname -a
Linux rpi3 4.14.48-v7 #1 SMP Sun Jun 10 17:15:22 EEST 2018 armv7l GNU/Linux
root<strong i="23">@rpi3</strong>:~# ethtool -K eth0 tx-tcp-segmentation off
root<strong i="24">@rpi3</strong>:~# ethtool -a eth0
Pause parameters for eth0:
Autonegotiate: on
RX: on
TX: on
RX negotiated: on
TX negotiated: on
root<strong i="25">@rpi3</strong>:/media/nas/public/soft/os# dd if=some_pesky_os.iso of=/dev/null iflag=direct bs=1M status=progress
4336910336 bytes (4.3 GB, 4.0 GiB) copied, 154 s, 28.2 MB/s
4159+1 records in
4159+1 records out
4362014720 bytes (4.4 GB, 4.1 GiB) copied, 154.879 s, 28.2 MB/s
MAU
1 Gbit
Flowcontrol "off" no interruptor
descarregamento de segmentação tcp desligado
nfs v4 _tcp_
root<strong i="35">@rpi3</strong>:~# ethtool -K eth0 tx-tcp-segmentation off
root<strong i="36">@rpi3</strong>:~# ethtool -a eth0
Pause parameters for eth0:
Autonegotiate: on
RX: on
TX: on
RX negotiated: off
TX negotiated: off
root<strong i="37">@rpi3</strong>:/media/nas/public/soft/os# dd if=some_pesky_os.iso of=/dev/null iflag=direct bs=1M status=progress
22020096 bytes (22 MB, 21 MiB) copied, 58 s, 378 kB/s^C^C
22+0 records in
21+0 records out
22020096 bytes (22 MB, 21 MiB) copied, 72.8616 s, 302 kB/s
Vou tentar usar o pi como normalmente faço com gbit / fc on / tcp-segmentation off e relatar se algo mudar depois de algum tempo.
asavah
em 11 jun. 2018
@asavah Obrigado pela confirmação - NFS TCP Eu posso lidar com falhas e significa que todas as observações são consistentes.
O controle de fluxo desligado sempre será ruim. Em algum ponto, devemos olhar para as mudanças do driver para recuar para 100 Mbits se não houver controle de fluxo, mas isso é uma prioridade ligeiramente inferior.
Obrigado por experimentar gbit / fc on / tcp-segmentation off - pessoas que estão preparadas para tentar coisas é a única maneira de chegarmos ao fundo disso.
6by9
em 11 jun. 2018
Em algum ponto, devemos olhar para as mudanças do driver para recuar para 100 Mbits se não houver controle de fluxo, mas isso é uma prioridade ligeiramente inferior.
Fiz uma tentativa rápida em uma tarde de sexta-feira sem sucesso, mas está na lista para ser revisada.
pelwell
em 11 jun. 2018
E o relatório @hidetosaito de 12 de maio, que a alteração do cabo CAT 5e para CAT 6 resolveu o bloqueio do scp. Só consigo encontrar o cabo CAT 6 em lojas locais.
No entanto, quando substituo o cabo Ethernet de CAT5e para CAT6, ele resolveu dramaticamente em meu ambiente. Eu nunca encontro o travamento quando o SCP e o Plex Media Server são iguais ao meu antigo 3B.
Além disso, teste o download do iperf3 para Pi3B +. Atualmente com CAT5e de Pi para um Mac (sem roteador), o download para Pi é 100 Mbps mais lento do que o upload (Retr mostra 0). Além disso, notei que a velocidade de download diminuiu cerca de 8 Mbps no último Raspbian (4.14 - 2018-04-18) em comparação com a versão de março (4.9.80-v7 +).
fieryo
em 12 jun. 2018
Testei com um cabo de categoria 6 logo após a solução @hidetosaito . Mas isso não resolveu nada: /. é uma loucura há 3 meses o problema está aí e não existe solução para este problema! Testei tudo e continuo convencido de que está no gerenciamento da fila do motorista. A cada falha de rede, há muito Send-Q (netstat -n)
Voltei para o meu framboesa 2b ...
Knoppix1
em 12 jun. 2018
@ JamesH65
Analisei mais detalhadamente minhas chaves de rede (Zyxel GS-108S v2) e meu adaptador de rede Realtek: FlowControl está ligado
NorbertM21
em 12 jun. 2018
@fiery TBH Não acredito que mudar de CAT5e para CAT6 terá qualquer efeito sobre o problema que está sendo discutido aqui (transferência de arquivos travando). Por que um cabo seria capaz de dizer que uma grande transferência está em andamento em comparação com pequenas transferências? Se você tiver um cabo CAT5e duvidoso, posso acreditar que trocá-lo por um bom cabo CAT6 (ou um bom cabo CAT5e) resolveria os problemas observados.
@ Knoppix1 Se você está convencido de que é um problema de gerenciamento de fila, sinta-se à vontade para pesquisar o código do kernel e corrigi-lo! Obviamente, é um problema trivial para você resolver em algumas horas.
No mundo real, parece que estamos reduzindo o problema, apesar de ainda não sermos capazes de reproduzi-lo aqui, muito menos ter um caso de teste de falha garantido. Não sei se isso significa que é dependente de hardware ou requer um conjunto específico de opções de configuração.
No entanto, um pedido educado - por favor, mantenha o assunto em questão: as transferências de arquivos estão parando, não diminuindo as reclamações, nem acrescentando outras observações aleatórias.
6by9
em 12 jun. 2018
@ 6by9 quando você escreveu:
No mundo real, parece que estamos reduzindo o problema, apesar de ainda não sermos capazes de reproduzi-lo aqui, muito menos ter um caso de teste de falha garantido.
Você quis dizer que você não foi capaz de reproduzir em sua configuração específica ou não foi capaz de reproduzi-la em nenhuma configuração (por exemplo, a minha mencionada em meu post acima)?
Acho que minha configuração é o mais simples possível. Basta anexar uma unidade externa (estou usando o Samsung EVO 850), formatar para NTFS e executar transferências SFTP do RPi. Use arquivos grandes para o teste de vários GB. Depois de várias transferências e algum tempo após a inicialização (parece também estar relacionado ao tempo de atividade), você deve acertá-lo.
risa2000
em 12 jun. 2018
Você quis dizer que você não foi capaz de reproduzir em sua configuração específica ou não foi capaz de reproduzi-la em nenhuma configuração (por exemplo, a minha mencionada em meu post acima)?
Há pelo menos 3 de nós que estão investigando isso nas Torres Pi. Nenhuma das configurações que qualquer um de nós apresentou apresentou problema, mesmo fazendo exatamente o mesmo que várias pessoas descrevem. Temos uma mistura de dispositivos em cabos de rede estupidamente curtos para switches locais não gerenciados e 40m + de volta para os switches corporativos. Os testes foram executados para caixas do Windows, caixas do Ubuntu, Ubuntu em VMs e para outros Pis. Existem tantas permutações que é a proverbial agulha no palheiro.
Acho que minha configuração é o mais simples possível. Basta anexar uma unidade externa (estou usando o Samsung EVO 850), formatar para NTFS e executar transferências SFTP do RPi. Use arquivos grandes para o teste de vários GB. Depois de várias transferências e algum tempo após a inicialização (parece também estar relacionado ao tempo de atividade), você deve acertá-lo.
James tentou isso. Funcionou bem: - /
Se estiver relacionado ao tempo de atividade, a depuração será ainda mais lenta, mas será investigada.
6by9
em 12 jun. 2018
@ 6by9 Obrigado pela explicação. Eu estava perguntando também porque percebi que ultimamente tem havido muito foco no tópico sobre a configuração da rede. Minha experiência (embora anedótica) sugeria que também pode haver alguma dependência de outros recursos do sistema (falta de). Não fiz nada como NFS ou Samba share do RPi, apenas SFTP usando o servidor SFTP nativo, mas percebi ao tentar diferentes sistemas de arquivos que:
1) Não encontrei o problema ao usar o cartão SD como fonte de transferência SFTP (pode ser porque eu não dei ênfase suficiente, mas em minhas várias tentativas funcionou bem).
2) Consegui resolver o problema quando a fonte de transferência era uma partição ext4 em um SSD externo conectado por ASMedia ASMT1051 USB <> ponte SATA (Samsung EVO 850). Enquanto eu acertava o problema lá, foram necessárias muito mais tentativas / transferências, e provavelmente acertei por sorte.
3) Eu estava enfrentando o problema de forma bastante consistente quando o SSD externo usava partição NTFS.
Escrevi razoavelmente, porque às vezes logo após a reinicialização, parecia estar funcionando bem, mas depois de um tempo (10-30 minutos) começou a acontecer de forma consistente. Às vezes eu era capaz de acertar imediatamente. Deve estar relacionado a alguns serviços que eu estava executando.
Fiquei tentado a concluir que não apenas a rede (ou talvez nem a rede), mas algum outro recurso do sistema operacional fica sem energia, seja em HW ou em um nível de software muito baixo. Enquanto eu estava executando as transferências, percebi que as velocidades de transferência eram de aproximadamente 20 MiB / s, quase maximizando as velocidades da interface nativa no RPi 3b +. O outro pensamento foi que talvez devido ao mecanismo diferente de montagem como NTFS foi montado usando FUSE, em comparação com ext4 ou sistema de arquivo de cartão SD nativo usando montagem nativa, pensei que talvez as opções de contexto adicionais (se houver) necessárias para NTFS poderiam adicionaram uma pressão adicional ao sistema.
Como a maioria das pessoas que estão enfrentando esse problema também está relatando a execução de algum tipo de configuração de unidade externa, com diferentes formas de expor essas unidades (NFS, samba), eu me pergunto se o problema pode realmente ser apenas isolado do problema de pilha de rede, ou precisamos considere também as outras circunstâncias, em particular o tráfego USB de / para a unidade externa. Minha experiência com cartão SD, ext4 e NTFS sugere que sim.
risa2000
em 12 jun. 2018
@ 6by9 Tentei executar o dumpcap ontem à noite, conforme sugerido por @pelwell, para tentar obter um log para vocês, mas parece que não está funcionando ...
sudo dumpcap -i eth0 -w <file.cap> -b filesize:32768 -b files:128
A princípio, o comando não retornaria nenhum arquivo ou diretório para o arquivo de saída, mas, uma vez que passei, ele apenas cuspiu um arquivo vazio e parecia sair imediatamente. Não tenho certeza do que está acontecendo lá, talvez eu esteja faltando alguma coisa? Este aplicativo é completamente novo para mim lol.
joickle
em 12 jun. 2018
Não posso testar por conta própria agora, mas sugiro que você tente executá-lo interativamente para ver se há algum erro:
sudo dumpcap -i eth0
@pelwell Sem erros com esse comando, ele criou o log /tmp/wireshark_eth0_20180612165321_nsfQXg.pcapng e atualmente está contando os pacotes.
joickle
em 12 jun. 2018
Eu tenho um arquivo de log, porém ele é muito grande (96 MB) e estava em execução no pi quando uma transferência de smb do pi para o Windows falhou. Parece haver alguns erros aí, mas seria necessário um olho mais experiente do que o meu para fazer algum sentido nisso.
joickle
em 12 jun. 2018
Eu estava trabalhando com uma captura de 7 GB outro dia - vamos lidar com 96 MB. Você pode fazer o upload em algum lugar - DropBox, Google Drive etc. - e postar o link?
pelwell
em 12 jun. 2018
Aqui está https://www.dropbox.com/s/rj9edqkhzyzeo37/wireshark_eth0_20180612171150_8e8s0o.pcapng?dl=0
joickle
em 12 jun. 2018
Obrigado @joickle. Vou vasculhar o lixo.
Pode não ser nada, mas posso sugerir que você faça algumas verificações de malware em sua rede. No despejo, há uma sessão TCP ímpar de / para 192.168.1.2 e 192.168.1.1 na porta 420. netstat -npa | less em seu Pi deve listar o processo proprietário de cada conexão. Eu esperaria ver uma linha na primeira seção da saída
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
...
tcp 0 200 192.168.1.2:420 192.168.1.1:xxx ESTABLISHED <PID>/<program>
A porta 420 é nominalmente atribuída para dados de timecode SMPTE (bastante incomum), mas também está vinculada a vários programas de malware https://www.speedguide.net/port.php?port=420. Também é possível que seja um aplicativo seu fazendo coisas perfeitamente inocentes, mas achei melhor sinalizá-lo.
6by9
em 13 jun. 2018
Parece que há algo errado na nova tentativa do TCP. Infelizmente, eu realmente poderia fazer com o outro lado do link.
Para documentar minha análise (*), as coisas deram errado em torno do pacote 17724. Estou filtrando o despejo no Wireshark por tcp.port == 445 portanto, estou apenas olhando para o tráfego do Samba - verificarei tudo mais tarde.
- 17733 é o ACK para o seq num 924391058, que era o último segmento do buffer 17718. Tudo bem.
- 17736 é o ACK para o seq num 924430478, que era o último segmento do buffer 17724.
- Obtemos uma duplicata daquele ACK microssegundos mais tarde em 17737, provavelmente acionado pela outra extremidade recebendo um pacote fora de ordem posteriormente no fluxo (então, o que aconteceu com o próximo pacote? Precisamos de erros de rede intermitentes / pacotes descartados para reproduzir isso? )
- Normalmente, você esperaria que o TCP tentasse novamente o buffer 17725 (o próximo bloco de dados) após um período de tempo limite, mas isso nunca acontece.
- 30 segundos depois, você obtém 18016 com 192.168.1.132 enviando um keep-alive para garantir que a sessão não expire. Isso é imediatamente reconhecido em 18017, então a conexão TCP ainda está ativa.
- O mesmo ocorre em 18351 e 18352, mais 30 segundos depois.
- 18384 é 192.168.1.132 desistindo e fechando a conexão.
Então, isso meio que aponta a culpa para o mecanismo de nova tentativa do TCP, que seria comum em muitas situações. Por que o descarregamento de segmentação parece destruir isso? No momento, não tenho ideia.
(*) Meu conhecimento de rede está um pouco enferrujado, então há atualizações mais recentes no TCP das quais não estou ciente. O livro de W Richard Stevens "TCP / IP Illustrated Volume 1: The Protocols" é meu amigo, copyright 1994. Inclui muitos detalhes adoráveis sobre links SLIP e similares!
6by9
em 13 jun. 2018
@ 6by9 Na verdade estou usando a porta 420 para ssh, talvez eu deva alterá-la de volta para o padrão 22?
Se ajudar, meu pi é ip 192.168.1.2 e meu laptop windows é 192.168.1.132. Posso tentar obter outro log da extremidade receptora (windows) se isso puder ajudar a rastrear o problema.
joickle
em 13 jun. 2018
Novos bits de TCP - ACK seletivo (também conhecido como SACK). RFC 2018 em 1996. Há uma boa descrição em http://packetlife.net/blog/2010/jun/17/tcp-selective-acknowledgments-sack/
O receptor pode adicionar opções de TCP para denotar que falta uma seção no meio de um fluxo, de modo que o transmissor só precisa enviar o bit ausente, não todas as seções após o ACK duplicado.
O buffer 17736 está ACKing até 924430478, mas também já recebeu 924468438-924490338, portanto, há 37960 bytes ausentes (o buffer 17725 não saiu?)
17737 atualiza esse status para dizer que ainda está ACKing até 924430478, mas também recebeu 924468438-924494718 (todos os outros dados).
Então, por que o Pi não responde ao SACK da maneira esperada e tenta novamente 17725? Eu não sei.
Comentário interessante de David Miller (um dos principais desenvolvedores de rede Linux) para RHEL. https://bugzilla.redhat.com/show_bug.cgi?id=485292#c43
É um pouco estranho que todo o buffer não segmentado tenha desaparecido. Se fosse um problema de Ethernet, você esperaria perder ~ 1448 bytes de TCP de um único quadro Ethernet completo. Portanto, _pode_ (grande salto) apontar para um problema de USB em que a transferência é descartada, o que pode resultar da necessidade de executar a transferência também a partir de USB. Ou ainda pode ser que o adaptador de LAN receba a solicitação e a descarte por motivos desconhecidos.
De qualquer maneira, a pilha TCP deve tentar novamente o buffer perdido e solucionar o problema - ela tem o objetivo de fornecer a garantia de entrega sobre o transporte não confiável de IP, então por que não?
6by9
em 13 jun. 2018
@joickle , fico feliz que seja inócuo :-)
Por ser SSH, não consegui ver dentro dele, e o número da porta parecia ter usos menos benignos. Eu descobri os endereços IP importantes para o que precisava.
Se você pudesse obter um download do Windows, isso poderia ser útil, mas não essencial.
Como acabei de postar, o dump tinha mais informações a fornecer, então agora preciso entender um pouco melhor como o Linux lida com o SACK.
James conseguiu algumas falhas agora, mas não tão confiável. Se for o caso, estarei hackeando o kernel para deliberadamente colocar 1 em N pacotes na esperança de recriar artificialmente a situação.
6by9
em 13 jun. 2018
Parece que vocês podem estar ganhando algum progresso :)
Aqui está uma amostra do Windows: https://www.dropbox.com/s/x3azsl6bc2ibh1u/windows_log.pcapng?dl=0
joickle
em 13 jun. 2018
Obrigado. Isso confirma que SACK não está se recuperando.
Nessa captura, tudo está OK até o pacote 283335.
- Como observa o Wireshark, para o buffer 283336, um segmento anterior não foi capturado. 17520 bytes estão ausentes com base nos números de sequência (o número de sequência esperado era 188123878, mas era 188141398).
- Buffer 283347 ACKs para 188123878 (buffer 283335), com SACK definido para 188141398-188157458 (buffers 283336-283346).
- Em seguida, obtemos ACKs duplicados para 188123878 (buffer 283335) com o intervalo SACK se estendendo cada vez mais à medida que mais dados são recebidos.
- O buffer 285250 eliminou mais alguns dados (33580 bytes), então acabamos com os intervalos de SACK de 188141398-190788378 e 190821958-190848238, com o segundo se estendendo.
- No buffer 286510, estamos no ACK número 392 duplicado e, nesse ponto, o Pi não envia mais dados sobre aquela sessão. SACK ainda está dizendo que temos 188141398-190788378 e 190821958-1992235238.
- Existem keep-alive regulares enviados por .132 que o Pi ACKs.
- Os dados ausentes parecem nunca ser retransmitidos.
6by9
em 13 jun. 2018
As discussões internas concluíram que vamos desativar todo o descarregamento de segmentação TCP por enquanto. A sobrecarga de desempenho não é mensurável usando ferramentas padrão, portanto, não é uma perda tão grande.
As investigações continuarão tentando entender por que o SACK está errado para nós, mas isso resolverá o problema por enquanto.
Um grande obrigado a @joickle por executar tantos testes para nós.
6by9
em 13 jun. 2018
@ 6by9 Sem problemas :-)
Como ainda estou executando a versão estável mais recente 4.14.34, há uma maneira de fazer sudo ethtool -K eth0 tx-tcp-segmentation off persistir entre as reinicializações até que uma correção permanente seja lançada? Ou seria melhor executar uma atualização de rpi?
joickle
em 13 jun. 2018
Eu não tentei ainda, mas https://forum.ivorde.com/linux-tso-tcp-segmentation-offload-what-it-means-and-how-to-enable-disable-it-t19721.html implica que você pode fazer isso via / etc / network / interfaces. Stretch moveu a maioria das coisas de lá para o dhcpd, então não tenho certeza se isso funciona.
/etc/network/if-up.d é mais provável - vou brincar enquanto espero o kernel compilar e relatar de volta.
6by9
em 13 jun. 2018
Verificando com nosso especialista em empacotamento Raspbian, a configuração com / etc / network / interfaces é que se você pode colocar todo o clichê normal lá e ele sobrescreverá dhcpd, mas então você está em uma configuração fora do padrão. Ele não sabe como via dhcpd.
Adicionar scripts a /etc/network/if-up.d funciona apenas se a interface for definida em / etc / network / interfaces.
Temporariamente, se você quiser fazer isso, então parece que consigo o resultado desejado com
# interfaces(5) file used by ifup(8) and ifdown(8)
# Please note that this file is written to be used with dhcpcd
# For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
pre-up ethtool -K eth0 tx-tcp-segmentation off tx-tcp6-segmentation off
# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d
em / etc / network / interfaces, mas não ofereço nenhuma garantia disso!
6by9
em 13 jun. 2018
@joickle
Foi o que eu usei
sudo nano /etc/systemd/system/[email protected]
Cole isto:
[Unit]
Description=Disable offload on NICs
DefaultDependencies=no
Before=network-pre.target
Wants=network-pre.target
Wants=systemd-modules-load.service local-fs.target
After=systemd-modules-load.service local-fs.target
Conflicts=shutdown.target
Before=shutdown.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/sbin/ethtool -K %i tso off
[Install]
WantedBy=multi-user.target
Salve o arquivo.
Corre
sudo systemctl daemon-reload
sudo systemctl enable ethtool-offload<strong i="14">@eth0</strong>
sudo systemctl start ethtool-offload<strong i="15">@eth0</strong>
Edit: caminho de ethtool fixo, meu sistema operacional não tem divisão / usr, desculpe.
asavah
em 13 jun. 2018
Obrigado pessoal, vou tentar estes :)
joickle
em 13 jun. 2018
Tenho a suspeita de que não é apenas uma solução alternativa, é a solução. Não seria a primeira vez que o lan78xx fingiria um recurso que não é compatível.
Em 2013, havia um patch muito semelhante para o smsc75x, então talvez precisemos descartar o NETIF_F_SG também.
lategoodbye
em 13 jun. 2018
@lategoodbye Hmm, se skb_linearize está fazendo o que parece (ou seja, convertendo de SG em linear), então acho que concordo com você que SG não é suportado, embora da maneira normal de um engenheiro, eu gostaria de confirmar que meu entendimento está correto.
Acho que também me lembro de ter lido que TSO _requires_ SG (não consigo ver a referência rapidamente agora) e, portanto, se não houver SG, então TSO é inválido. Parece uma pena ver que parece funcionar (ignorando as paradas), mas não há ganho se estiver copiando em outro lugar.
Interessante notar que r8152.c anuncia SG | TSO | TSO6 e não chama skb_linearize, então não estou certo se é uma limitação fundamental dos adaptadores LAN USB ou apenas uma peculiaridade de alguns dispositivos.
Daft pensou, eu me pergunto se os pacotes perdidos são devido à falha de skb_linearize e, portanto, ao envio de algo sem sentido para o adaptador.
...
OK, ele lida com o valor de retorno de skb_linearize corretamente e deve incrementar tx_errors e tx_dropped, mas não diz às camadas acima que falhou.
6by9
em 13 jun. 2018
Apenas uma nota rápida para quem está tentando fazer com que a solução alternativa persista nas reinicializações.
Adicionar ethtool -K eth0 tx-tcp-segmentation off tx-tcp6-segmentation off em /etc/rc.local antes da linha de saída também parece funcionar.
O método /etc/network/interfaces acima não funcionou para mim, ele relatou que o dhcpcd falhou ao iniciar na inicialização :(
joickle
em 13 jun. 2018
@ 6by9 Hoje consegui reproduzir a parada uma vez (enviando arquivo de 4 GB armazenado em HDD externo (NTFS) do RPi 3 B + para o notebook Linux). Não tenho certeza se está relacionado, mas desabilitei o GSO e deixei o TSO habilitado antes via ethtool. Após a paralisação, as estatísticas de / sys / class / net / eth0 / statistics mostraram um 2 para tx_error e tx_dropped.
lategoodbye
em 13 jun. 2018
Tenho esses problemas principalmente ao enviar arquivos PARA ao Pi, não DO Pi.
NorbertM21
em 14 jun. 2018
O kernel rpi-update mais recente inclui a solução alternativa de @ 6by9
popcornmix
em 14 jun. 2018
@lategoodbye Eu acho que você pode ter me cutucado na direção certa lá no skb_linearize.
Adicionando um parâmetro de módulo simples para um nível de queda e falhando artificialmente em lan78xx_linearize quando essa contagem atinge, vejo uma paralisação garantida todas as vezes. Na verdade, estou usando scp para fazer a cópia em vez de nfs ou samba, mas isso parece ser qualquer coisa sobre TCP.
Os dumps do Wireshark mostram o mesmo sintoma de ACKs duplicados repetindo o mesmo segmento como tendo sido perdidos, mas nunca são reenviados.
Desative a segmentação tx-tcp e ainda recebo 178 ACKs duplicados com informações de SACK, mas o Pi retransmite os pacotes ausentes e as coisas são retomadas normalmente.
(Um pouco curioso que pareço ter 24616 (17 * 1448) bytes perdidos no stream, embora eu só falhe em uma chamada skb_linearize. Eu esperava não receber pacotes não segmentados passados com isso desativado. Generic-segmentation-offload ainda está ativado, então talvez seja apenas um redirecionamento de parte do TCP).
Estamos chegando ao estágio em que podemos postar um relatório sensato no net-dev :-)
6by9
em 14 jun. 2018
Encontrou uma referência que o TSO requer SG - https://wiki.linuxfoundation.org/networking/tso
Comparando com o driver r8152 acho que não há nada que impeça o lan78xx de fazer SG.
Ambos requerem um buffer linear, assim como a cópia de dados de um skb para um urb. Enquanto lan78xx usa skb_linearize e passa o buffer resultante para usb_fill_bulk_urb, r8152 parece copiar todos os fragmentos em um buffer struct tx_agg que alocou e então o envia.
6by9
em 14 jun. 2018
O WiFi é afetado? Desativar "tx-tcp-segmentation" também é necessário para esta interface?
fieryo
em 14 jun. 2018
Não e não.
pelwell
em 14 jun. 2018
sudo ethtool -k wlan0 teria dito a você que nenhum mecanismo de descarregamento de segmentação é compatível com o adaptador wi-fi, portanto, não há como ser afetado.
Não eliminei a possibilidade de haver um bug genérico no TCP com tso ativo em caso de perda de pacotes, no entanto, parece haver um problema no driver LAN78xx que pode resultar em perda de pacotes no driver, então pode ser mais fácil de ativar.
6by9
em 14 jun. 2018
Tendo exatamente o mesmo problema, aqui, com CentOS 7.5 (recentemente atualizado pelo YUM) com kernel 4.14.43.
Contexto:
SSH estagnou e expirou, na transferência de arquivos enormes de RPI 3B + para qualquer Linux-box (bare metal ou máquinas virtuais).
Isso acontece depois de alguns 10 Mb, geralmente menos de 200 Mb.
O arquivo enorme é basicamente um .img modificado, contendo minha própria imagem personalizada (> 3Gb).
Tentei alguns SD diferentes, de diferentes tamanhos e marcas com o mesmo efeito.
100% reproduzido
O mesmo SD inserido em um 3B funciona perfeitamente com o mesmo procedimento de transferência de arquivos para os mesmos servidores.
Leia alguns outros posts / tópicos / sites, aqui ou ali. Nada funcionou, até agora.
Esqueci de mencionar que não observo nenhum OOPS no kernel.
Leia este tópico e tente o seguinte:
dd if=/dev/zero bs=1M status=progress | ssh user<strong i="16">@target</strong> "cat >/dev/null"
A transferência está bem para pelo menos 1,5 Gb (tive que cortar o comando), o que é muito melhor do que o que eu tinha anteriormente, mas eu preciso copiar um arquivo real ... / dev / zero não é tão interessante :-)
Então, eu tentei isso:
sudo ethtool -K eth0 tx-tcp-segmentation off tx-tcp6-segmentation off
Até agora, isso parece funcionar em algumas tentativas.
Espero que isto ajude.
stephan57160
em 27 jun. 2018
@ stephan57160 A desativação do TSO por padrão ocorreu com 4.14.49, portanto, rodando em um 4.14.43 sem patch, eu esperaria ver problemas.
Não mantemos o CentOS, portanto, não há muito que possamos fazer para implementar a correção.
Pelo menos a confirmação de que sudo ethtool -K eth0 tx-tcp-segmentation off tx-tcp6-segmentation off resolve o problema confirma que é o mesmo problema e não temos que sair à caça de outro problema.
6by9
em 27 jun. 2018
Nenhum problema para CentOS. Eu esperava esta resposta, sim :-)
Pelo menos, agora posso apontar isso para os mantenedores e esperar por uma atualização de sua parte.
Obrigado de qualquer maneira pelo trabalho.
stephan57160
em 27 jun. 2018
Uma solução alternativa systemd-networkd até que a correção do kernel esteja disponível. Eu, por exemplo, uso kernels upstream com Arch Linux ARM. Cole o seguinte em /etc/systemd/network/00-lan78xx.link e reinicie:
[Match]
Driver=lan78xx
[Link]
TCPSegmentationOffload=no
TCP6SegmentationOffload=no
lassebm
em 12 jul. 2018
A correção do kernel já está em nossa versão atual do Raspbian. apt get update / upgrade deve obtê-lo.
Também temos uma correção recente para outro isue lan78xx, que corrige grandes transferências que causam oops no kernel, geralmente envolvendo dispositivos USB conectados. Isso está em atualização rpi.
JamesH65
em 12 jul. 2018
@ JamesH65 Você sabe se essas correções estão sendo
lassebm
em 12 jul. 2018
@lassebm
Sim, este: https://github.com/raspberrypi/linux/commit/58ab5c274ae0347a949e98f51e646df58f572535
Não, aquele aqui: https://github.com/raspberrypi/linux/commit/db81c14ce9fbd705c2d3936edecbc6036ace6c05
Mas você pode escolher o último, que fiz por 4,16
mkreisl
em 12 jul. 2018
Acredito que https://github.com/raspberrypi/linux/commit/db81c14ce9fbd705c2d3936edecbc6036ace6c05 está sendo upstreamed (ou pelo menos enviado para lá!) Na próxima semana. Eu não posso ver isso causando muito tumulto.
JamesH65
em 12 jul. 2018
Há alguma chance dessas correções de lan78xx serem retransmitidas para 4.9.y?
smp79
em 24 jul. 2018
Não tenho certeza se você está falando sobre a árvore da Fundação ou Mainline?
A correção para a condição de corrida foi portada para o Linux estável 4.9.114, 4.14.57 e 4.17.9
lategoodbye
em 24 jul. 2018
Se você está falando sobre Raspbian / nosso kernel, então não, eu duvido que faremos backport dele. Recomendamos mover para 4.14.
JamesH65
em 24 jul. 2018
Sim, eu estava falando sobre rpi-4.9.y. 4.14 e mais recentes atualmente não são uma opção para mim devido a esse problema não resolvido .
smp79
em 24 jul. 2018
Seria bastante fácil construir seu próprio kernel com este patch enquanto tentamos chegar ao fundo do outro problema.
JamesH65
em 24 jul. 2018
Seria bastante fácil construir seu próprio kernel com este patch enquanto tentamos chegar ao fundo do outro problema.
Não estou usando LE, mas não acredito que seja bastante fácil construir o próprio kernel para LE
mkreisl
em 24 jul. 2018
Não tenho certeza do que você entende por LE, mas aqui estão as instruções para construir seu próprio kernel. https://www.raspberrypi.org/documentation/linux/kernel/building.md
Clone o branch correto (rpi-4.9.x), aplique este patch (deve ser uma aplicação limpa), reconstrua.
JamesH65
em 24 jul. 2018
@ JamesH65
Meu Deus , se você lesse o problema
E sim, eu sei como construir o próprio kernel. Estou fazendo isso todos os dias para XBian
mkreisl
em 24 jul. 2018
Então, por que não digitar LibreElec e economizar muito tempo para todos? São apenas 7 personagens extras.
Não tenho ideia das complexidades de uma construção do LibreELEC (veja o que eu fiz lá?), Mas ainda é improvável que estejamos fazendo backport, então eu sugiro abordar o LibreELEC para consertar sua própria construção.
JamesH65
em 24 jul. 2018
No momento, o Pi3B + está absolutamente inutilizável, o Pi mais ruim de todos os tempos. Extremamente frustrante
@mkreisl
Seu problema foi resolvido? Estou em dúvida quanto a atualizar meu Pi3B para Pi3B +. Eu me pergunto se esses problemas de LAN já foram totalmente corrigidos.
smp79
em 26 jul. 2018
@ smp79
Não faço testes de estresse no Pi3B + há muito tempo, mas no ambiente padrão este dispositivo parece estar em um estado utilizável.
mkreisl
em 26 jul. 2018
@ smp79 No que diz respeito a nós, a correção da movimentação da fila de algumas semanas atrás foi a maior, e esperamos que ela conserte a grande maioria dos problemas que as pessoas estavam vendo com o lan78xx. Combine isso com algumas outras correções que foram feitas, tanto para o lan78xx quanto para as mudanças na velocidade do clock, e esperamos que o Pi3B + seja pelo menos tão robusto quanto o 3B. Claro, ainda pode haver problemas não relatados / inesperados, mas agora devem ser poucos e distantes entre si. Ainda existem alguns problemas pendentes no sistema sem fio, mas são casos extremos e estão sendo resolvidos pela Cypress.
JamesH65
em 26 jul. 2018
Olá, leia a maioria dos comentários aqui e vi todos esses commits, mas ainda estou confuso sobre isso. Então, uma correção está sendo trabalhada, certo? Posso ajudar fornecendo algumas informações?
Este bug torna meu Pi3 B + quase inútil, então eu gostaria de perguntar se há algum HEC.
headlesscyborg
em 24 out. 2018
@headlesscyborg No que nos diz respeito, o problema foi contornado e as pessoas não deveriam estar observando os problemas de rede. (Você me lembrou que não fiz as perguntas no net-dev).
Você não forneceu detalhes sobre sua configuração e os problemas que está vendo, portanto, não podemos ajudá-lo.
Se uname -a não relatar que você está executando 4.14.49 ou posterior, atualize seu sistema. Além disso, você precisa fornecer o máximo de detalhes possível para nos dar uma chance ainda vaga de reproduzir o seu problema.
6by9
em 24 out. 2018
Você está usando o Raspbian mais recente? Não estamos fazendo nada sobre isso no momento, porque acreditamos que está funcionando bem. Se você ainda está tendo problemas com o Raspbian / kernel mais recente, então precisaremos dar uma olhada.
JamesH65
em 24 out. 2018
Modelo: Raspberry Pi 3 B +
Kernel: 4.14.71-v7+ #1145 SMP Fri Sep 21 15:38:35 BST 2018 armv7l GNU/Linux
Distribuição:
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
Atualizações do sistema: totalmente atualizado
Eu tenho meu Pi conectado à rede usando uma rede com fio RJ45, executando o Raspbian 9 totalmente atualizado de um SSD externo conectado via USB. Tudo funciona como exceção, exceto a transferência de arquivos pela rede usando FTP ou SFTP - exatamente como descrito na postagem original, ele transfere uma quantidade aleatória de dados (~ 30 MB por exemplo) com velocidade de ~ 6-10 MB / s, em seguida, para e após 10 -30 segundos, a transferência continua com velocidade de apenas ~ 50-150 KB / s e quedas frequentes.
Isso só acontece nas seguintes situações:
- o arquivo é transferido do Pi para outro dispositivo a partir de um dispositivo USB externo (SSD externo, unidade flash USB externa etc.) conectado ao Pi
Isso não acontece nas seguintes situações:
- o arquivo é transferido do Pi para outro dispositivo do leitor de cartão SD interno incluído no Pi
- o arquivo é transferido de outro dispositivo para um dispositivo USB externo (SSD externo etc., ainda não tentei transferir para uma unidade flash USB) conectado ao Pi
Informação adicional:
- meu AP / roteador Wi-Fi (no qual o Pi está conectado usando um fio RJ45) é Asus RT N11P
- não há diferença de comportamento entre conexão com fio e sem fio
Meus outros dispositivos que uso para transferir arquivos de / para o Pi são:
- um laptop com Arch Linux, nenhuma diferença entre Wi-Fi e conexão RJ45 com fio, o laptop tem um SSD M2 NVME, então não deve haver nenhum problema com a velocidade do disco rígido (tentei o suporte FTP / SFTP integrado do Nautilus, bem como o Filezilla e Firefox FTP)
- um smartphone Android - HTC U11 conectado usando Wi-Fi (ES File Explorer SFTP / cliente FTP)
- exatamente o mesmo comportamento em ambos os dispositivos em todos os clientes SFTP / FTP que tentei
EDIT: Fiz algumas mudanças na maneira como descrevi quando isso acontece e quando não acontece, para que pareça menos confuso.
headlesscyborg
em 24 out. 2018
Forneça o resultado de sudo ethtool -k eth0 , sudo ethtool -a eth0 e sudo ethtool -S eth0 .
Idealmente, forneça uma captura usando tcpdump ou arameshark ao tentar uma dessas transferências.
Algo estranho conectado dmesg ?
Com 4.14.71 você pode ver hw csum failure mensagens - esse era um bug que foi introduzido no kernel da linha principal e acabou de ser resolvido, mas ainda não foi propagado para os repositórios Raspbian.
6by9
em 24 out. 2018
Saídas:
https://gist.github.com/headlesscyborg/a2fa690f70079403a4e5edb4309f1704
https://gist.github.com/headlesscyborg/2e64e375d6938afabf2547c3e997718e
https://gist.github.com/headlesscyborg/007159ab6b8fb02285807d668484e757
https://gist.github.com/headlesscyborg/1689f544ce6314f5c8535c78e98c07d9
Infelizmente, não posso fornecer saídas Wireshark porque congelou completamente o Pi (ou sessões VNC / SSH - não tenho monitor conectado a ele) após um minuto.
No entanto, eu estava testando a transferência de arquivos SFTP hoje e, por algum motivo, ela funciona agora. Estranho porque estava tendo o problema nos últimos 2 meses sempre que tentei e agora, quando finalmente relatei aqui, ele simplesmente desapareceu. Estarei testando nos próximos dias.
headlesscyborg
em 26 out. 2018
@pelwell @ JamesH65 Estamos felizes em fechar este agora? TSO foi a causa principal, portanto, quaisquer novos relatórios realmente precisam passar por uma triagem completa, em vez de serem marcados com isso.
6by9
em 26 out. 2018
Estou feliz por encerrar o problema, mas devemos apoiar @headlesscyborg aqui, pois já começamos.
pelwell
em 26 out. 2018
Deixe-o aberto por alguns dias para que @headlesscyborg volte e feche se for resolvido?
6by9
em 26 out. 2018
Acho isso razoável.
pelwell
em 26 out. 2018
@pelwell 18 dias e nenhuma resposta de @headlesscyborg. Feliz em fechar?
6by9
em 13 nov. 2018
sim. @headlesscyborg - abra um novo problema se o problema persistir, copiando todas as informações relevantes desse problema.
pelwell
em 13 nov. 2018
Questões relacionadas
ensarkarabudak
·
7Comentários
incyi
·
9Comentários
wudo94
·
5Comentários
kucharskim
·
7Comentários
ncguk
·
4Comentários
Comentários muito úteis
Tenho exatamente o mesmo problema e fico feliz em ver que não estou sozinho nisso, depois de reiniciar posso transferir arquivos através do sftp (usando o filezilla no Windows) sem problemas, mas depois de meia hora ou mais depois de inicializar as transferências don não funciona mais: ele trava após um ou dois segundos de transferência em alta velocidade (18 MBps), depois atinge o tempo limite e tenta se reconectar após 20 segundos, apenas para falhar novamente após um ou dois segundos de transferência. Eu também tentei o mesmo com a transferência dos arquivos do cartão SD (sem hdd conectado) e tem os mesmos problemas, quando coloco o cartão SD em um 3B ele não tem problemas em transferir esses arquivos até mesmo do disco rígido.
Estou usando o Raspbian e o carregador oficial Raspberry Pi, se isso ajudar.
Se for relacionado a hardware, adoraria saber para que possa ser trocado pelo vendedor.