macOS 10.12.6: Panico, asserzione non riuscita: ifp-if_sndbyte_total = len, bsd / netinet / in_pcb.c, riga: 3458

3

Ricevo panico del kernel sporadico come questo:

*** Panic Report ***
panic(cpu 3 caller 0xffffff80189d435f): assertion failed: ifp->if_sndbyte_total >= len, file: /Library/Caches/com.apple.xbs/Sources/xnu/xnu-3789.70.16/bsd/netinet/in_pcb.c, line: 3458

[…]

Mac OS version:
16G29

Kernel version:
Darwin Kernel Version 16.7.0: Thu Jun 15 17:36:27 PDT 2017; root:xnu-3789.70.16~2/RELEASE_X86_64
Kernel UUID: [REDACTED]
Kernel slide:     0x0000000018200000
Kernel text base: 0xffffff8018400000
__HIB  text base: 0xffffff8018300000
System model name: MacBookPro12,1 (Mac-[REDACTED])

System uptime in nanoseconds: 205886295907546
last loaded kext at 205508810738561: com.apple.driver.usb.cdc   5.0.0 (addr 0xffffff7f9b612000, size 28672)
last unloaded kext at 196312576713453: com.apple.driver.usb.AppleUSBHostCompositeDevice 1.1 (addr 0xffffff7f9b60b000, size 28672)

[…]

( trova il resto del registro in questo gist )

Ho letto la nota tecnica Apple sul debug di Kernel Panics , ma non è riuscito a trovare il modo di applicarlo a questo panico, inoltre il link per scaricare il Kernel Debug Kit è rotto, quindi non sono riuscito a ottenere una mappatura di kex nella memoria del kernel - iow, non so cosa è stato caricato in% % co_de.

Ho letto anche il codice sorgente , che "gestisce [s] i blocchi di controllo del protocollo", cioè tutto il mantenimento dello stato per i socket TCP. La funzione in questione è:

inline void
inp_incr_sndbytes_unsent(struct socket *so, int32_t len)
{
  struct inpcb *inp = (struct inpcb *)so->so_pcb;
  struct ifnet *ifp = inp->inp_last_outifp;

  if (ifp != NULL) {
    VERIFY(ifp->if_sndbyte_unsent >= 0);
    OSAddAtomic64(len, &ifp->if_sndbyte_unsent);
  }
}

che mi suggerisce che il problema è nello stack di rete e potrebbe avere qualcosa a che fare con il tenere traccia dei buffer, ma non sono abbastanza esperto di BSD o TCP per capire il flusso di controllo.

Sono in perdita per il modo migliore di eseguire il debug di questo ulteriore - la mia impressione è che ha a che fare con il client VPN (Pulse Secure, in precedenza Junos), ma non posso innescare il crash in modo affidabile, semplicemente accade con il tempo (e quando lo stavo osservando, accadeva solo mentre si trovava sul VPN, ma n = 2). Ho bisogno sia di uno scanner antivirus che di Pulse Secure per poter svolgere il mio lavoro.

UPDATE L'incidente si è appena verificato di nuovo dopo appena 6 ore di operatività, la maggior parte delle quali è stata spenta inattiva. Ho fatto una diagnosi ieri, ho preso tutto ok, ho avviato il computer al mattino, l'ho messo a dormire per colazione, sono andato in aeroporto, l'ho riaperto e si è schiantato dopo pochi (< 2) minuti. Ero su VPN quando si è svegliato. Inoltre, poiché si trattava di un crash piuttosto "pulito", gli ultimi kits caricati erano:

last loaded kext at 1743857437016: com.apple.driver.usb.cdc 5.0.0 (addr 0xffffff7f94191000, size 28672)
last unloaded kext at 898332773796: com.apple.driver.AppleIntelLpssI2C  3.0.60 (addr 0xffffff7f93853000, size 40960)

poiché non avevo collegato nessun dispositivo USB dall'ultimo avvio a freddo, suggerendo ancora una volta che non si tratta di un problema hardware o USB, ma di uno con lo stack TCP e / o TCP sul lato del kernel.

    
posta moeffju 12.09.2017 - 23:32
fonte

0 risposte

Leggi altre domande sui tag