Brief Intro : Computador, um belo dia, começou a reiniciar aleatoriamente. Nenhum padrão visto. Ocorre em qualquer lugar entre 1 a 8-9 vezes ao dia, geralmente 2-5. Pode ir 2-3 dias entre ocorrências. Reiniciar não envolve BSOD. Logs de eventos não oferecem dicas. Temps não são altos - aconteceu durante a carga ociosa. Detalhes abaixo, e no meu primeiro Q.
Esse Q acompanha Computador reinicia irregularmente - o que o service Center deve procurar?
A partir de agora, a placa-mãe acabou de ser substituída pela Gigabyte. A CPU foi substituída, a RAM foi substituída, mas o problema de reinicializações aleatórias continua.
Abaixo está um guia gráfico bruto para as permutações em que as reinicializações ocorreram.
Chave :
WP = Main or Wall Power source
IP = Intermediate Power Source a.k.a UPS
PSU = Computer Power Supply Unit - Corsair 550M
Cs = Computer case/cabinet
MB = Motherboard GA-H97-D3H
RAM - RC = 2x Corsair 4GB DDR3 1333
RK1 = 1x Kingston 8GB DDR3 1600
RK2 = 2x Kingston 8GB DDR3 1866
CPU = i5-4440
HDDs = WD 1TB Win 7 + Seagate 2TB OpenSuSE Linux Tumbleweed
OS = within Win7 / Linux / UEFI
No add-on graphics ever (at my end), only iGPU.
Estes são os cenários em que o sistema foi testado. FALHA no início significa reinicialização reproduzida; PASSE significa que nenhuma reinicialização será vista.
Se houver um sufixo - indica um componente alterado. Trailing ? indica que o componente pode não estar presente.
Em ordem cronológica ,
FAIL: WP - IP - PSU - Cs - MB - RC - CPU - HDDs - Win
FAIL: WP - IP - PSU - Cs - MB - RC - CPU - HDDs - Linux
FAIL: WP - IP - PSU - Cs - MB - RC - CPU - HDDs - BIOS
--- comp sent to dealer without HDDs --->
FAIL: WP_dlr - IP_dlr? - PSU - Cs - MB - RC - CPU - HDDs_dlr - Win_dlr
PASS: WP_dlr - IP_dlr? - PSU_dlr - Cs_dlr - MB - RC - CPU - HDDs_dlr - Win_dlr
(^ tested for less than a day)
--- comp returned to me with dealer PSU and Cs --->
FAIL: WP - IP - PSU_dlr - Cs_dlr - MB - RC - CPU - HDDs - Win
FAIL: WP - IP - PSU_dlr - Cs_dlr - MB - RK1 - CPU - HDDs - Win
(^ a week passed without restarts after switching to ram RK1)
FAIL: WP - IP - PSU_dlr - Cs_dlr - MB - RK1 - CPU - HDDs - Linux
contd ..
--- comp returned to dealer without HDDs --->
--- MB only forwarded to Gigabyte --->
PASS: WP_gb - IP_gb? - PSU_gb - Cs_gb? - MB - R_gb - CPU_gb - HDDs_gb? - ?
(^ burn-in test for 2 days)
FAIL: WP_gb - IP_gb? - PSU_gb - Cs_gb? - MB - RC - CPU - HDDs_gb? - ?
(^ sent my CPU + Corsair RAM)
--- Gigabyte return items to dealer; say one of the RC sticks to blame --->
PASS: WP_dlr - IP_dlr? - PSU - Cs - MB - 1xRC + RK1 - CPU - HDDs_dlr - Win_dlr
(^ tested intermittently over 3-4 days)
--- comp returned to me with "faulty" RAM removed --->
FAIL: WP - IP - PSU - Cs - MB - 1xRC + RK1 - CPU - HDDs - Win
--- MB+CPU+RAM(RC+RK1) resent to Gigabyte --->
(no testing done; CPU examined - observed some pins have blackened; say CPU to blame)
--- dealer replaces CPU with same model --->
PASS: WP_dlr - IP_dlr? - PSU_dlr - Cs_dlr - MB - 1xRC + RK1 - CPU_new - HDDs_dlr - Win_dlr
(^ tested for 3 days)
contd ..
--- comp returned to me with new CPU --->
FAIL: WP - IP - PSU - Cs - MB - RC + RK1 - CPU_new - HDDs - Win
FAIL: WP - IP - PSU - Cs - MB - RC + RK1 - CPU_new - HDDs - BIOS
--- MB+CPU_new+RAM(RC+RK1) sent to Gigabyte --->
PASS: WP_gb - IP_gb? - PSU_gb - Cs_gb? - MB - RC+RK1 - CPU_new - HDDs_gb? - ?
(^ testing setup and duration unknown but reported after 3 days; say PSU to blame)
At this stage, I call Gigabyte and explain testing history to site manager,
who offers replacement MB.
--- comp returned to me with RMAed MB --->
FAIL: WP - IP - PSU - Cs - MB_rma - RC + RK1 - CPU_new - HDDs - Win
PASS: WP - IP - PSU - Cs - MB_rma - RC + RK1 - CPU_new - HDDs - Linux
(^ a few hours)
FAIL: WP - IP - PSU - Cs - MB_rma - RC + RK1 - CPU_new - HDDs - BIOS
--- swap RAM with another (working) comp, yesterday --->
FAIL: WP - IP - PSU - Cs - MB_rma - RK2 - CPU_new - HDDs - Win
(PASS: WP_oth - PSU_oth - Cs_oth - MB_oth - RC + RK1 - CPU_oth - HDD_oth - Win)
Agora, pensando em qual é a minha próxima etapa de teste provavelmente atualizando isso para o departamento de teologia, mas verificará as sugestões temporais um pouco mais
.Se você ler o Q inicial, notará que o MB original foi enviado para a Gigabyte em junho. Ele foi enviado de volta reparado e com seu BIOS atualizado para a versão F7. A versão anterior era F3. A nova versão adicionou suporte para procs de quinta geração, eles também impedem as reversões do BIOS. O novo BIOS poderia ser responsável? A placa RMAed também possui F7. Contra essa possibilidade é o fato de que a atualização ocorreu em junho e o comportamento de reinício começou em meados de outubro.
O problema do drive que desapareceu não voltou desde o primeiro retorno da Gigabyte. Não há falhas durante qualquer uso do Windows ou Linux.
Provavelmente vou trocar a PSU com a composição de trabalho, embora uma configuração anterior tenha sido testada sem sucesso com a PSU do revendedor.
Obrigado pela leitura. Pensamentos?