MICROCHIP HBA 1200 Software-Firmware Note di rilascio Istruzioni

Informazioni su questa versione
La versione di sviluppo descritta in questo documento include firmware, driver del sistema operativo, strumenti e software di gestione host per le soluzioni HBA 1200 di Microchip.

Identificazione del rilascio
Le versioni di firmware, software e driver per questa versione sono mostrate nella tabella seguente.

Tabella 1-1. Riepilogo del rilascio

Rilascio soluzioni	3.1.4
Data di rilascio del pacchetto	10 agosto 2021
Versione del firmware	3.01.04.072
BIOS UEFI/precedente	1.4.3.6/1.4.3.2
Versioni del driver	Driver di Windows: • Windows 2019, 2016, Windows 10: 1010.6.0.1025 Linux SmartPQI: • RHEL 7/8: 2.1.12-055 • SLES 12/15: 2.1.12-055 • Ubuntu 18/20/21: 2.1.12-055 • Oracle Linux 7/8: 2.1.12-055 • Citrix Xenserver 8: 2.1.12-055 • Debian 9/10: 2.1.12-055 • CentOS 7/8: 2.1.12-055 VMware: • VMware ESX 6/7: 4150.0.119 FreeBSD/Solaris: • FreeBSD 11/12/13: 4130.0.1008 • Solaris: 11: 4120.0.1005
ARCONF/maxView	B24308

Files Incluso in questa versione
Questa sezione descrive in dettaglio il fileè incluso in questa versione.

Tabella 1-2. firmware Files

Componente

Descrizione

Uso pre-assemblaggio

Uso post-assemblaggio

SmartFWx200.bin

Flash NOR programmabile con firma di produzione File. Utilizzare per programmare NOR Flash per le schede che eseguono già il firmware.

Tabella 1-3. Strumenti di programmazione del firmware

Attrezzo	Descrizione	Eseguibile
ARCCONF	Utilità ARCCONF CLI	ARCCONF BXXXXX.zip
massimoView	massimoView Utilità	MassimoVIEW XXX BXXXXXX.zip

Autista Files

Tabella 1-4. Driver Windows

OS	Versione
Server2019, 2016, Windows 10	numero x64

Tabella 1-5. Driver Linux

OS	Versione
REL 8.4, 8.3, 8.2, 8.1, 7.9, 7.8, 7.7	numero x64
Cent OS 8.3, 8.2, 8.1, 8.0, 7.9, 7.8, 7.7	numero x64
SLES 12 SP5, SP4	numero x64
SLES 15 SP3, SP2, SP1	numero x64
Le versioni di Ubuntu 20.04.2, 20.04.1, 20.04, 18.04.5, 18.04.4	numero x64
Versione 21.04 di Ubuntu	numero x64
Oracle Linux 8.3, 8.2, 7.9, 7.8, UEK6U1 (5.4.17-2036)	numero x64
Oracle Linux 8.2 UEK R6	numero x64
Debian10.5	numero x64
Fedora 33 (posta in arrivo)	numero x64
Versione 8.2	numero x64

Tabella 1-6. Driver per FreeBSD, Solaris e VMware

OS	Versione
ESX6.5U3/U2	numero x64
ESX6.7U3/U2	numero x64
ESX7.0U2/U1	numero x64
FreeBSD 13, 12.2, 11.4	numero x64
Solaris 11.4	numero x64

Software di gestione dell'host

Tabella 1-7. maxView e Utilità ARCCONF

Descrizione	OS	Eseguibile
Utilità della riga di comando ARCCONF	Windowsx64Linuxx64 VMware 6.5 e versioni successive	Vedere arcconf_B#####.zip per gli eseguibili di installazione per il relativo sistema operativo.
	XenServer
	Supporto UEFI
massimoView Responsabile dell'archiviazione	Windowsx64Linuxx64 VMware 6.5 e versioni successive	Vedi il massimoview_linux_B#####.zip, massimoview_win_ B#####.zip e il maxview_vmware_B#####.zip per gli eseguibili di installazione.
	XenServer
	Supporto UEFI
massimoView plug-in vSphere	VMware 6.5 e versioni successive	Vedi il massimoview_vmware_B#####.zip per gli eseguibili di installazione.
Boot USB (offline o pre-boot) per ARCCONF e maxView Responsabile dell'archiviazione	Linuxx64	Vedi il massimoview_offline_bootusb_B#####.zi p per .iso file.

Cosa c'è di nuovo?

Questa sezione mostra le novità di questa versione.

Caratteristiche

La tabella seguente elenca le funzionalità supportate per questa versione. Tabella 2-1. Riepilogo delle caratteristiche

Caratteristiche		Supportato in questa versione	Versione futura
Driver UEFI, supporto di avvio		X
Supporto di avvio legacy		X
Gestione dinamica della potenza		X
Supporto per i conducenti	Finestre	X
	Linux	X
	VMware	X
	BSD libero	X
	Solare	X
	Certificazione del sistema operativo	X
Supporto Flash	Utilità ARCCONF	X
massimoView supporto dello strumento		X
Supporto dello strumento ARCCONF		X
MCTP Gestione BMC		X
Supporto 4Kn in RAID e HBA		X
Supporto della crittografia basata su controller (CBE)1		X
Supporto per la selezione dell'interfaccia fuori banda di MCTP o PBSI		X
Supporto backplane VPP		X
Supporto PBSI		X
Impostazioni SSU dell'espansore configurabili		X

Nota: Disponibile solo per i prodotti abilitati alla crittografia.

Correzioni e miglioramenti

Questa sezione mostra le correzioni e i miglioramenti per questa versione.

Correzioni del firmware

Questa sezione mostra le correzioni e i miglioramenti del firmware per questa versione.

Correzioni e miglioramenti per la versione firmware 3.01.04.072
Questa versione fornisce le seguenti correzioni e miglioramenti.

Migliorato l'output del registro seriale per l'inventario dei dispositivi collegati. In particolare, sono state migliorate le informazioni relative agli identificatori univoci del dispositivo NVMe e sono stati separati/riorganizzati diversi gruppi di informazioni per migliorare la leggibilità.
Aggiunto il supporto per segnalare un ID SCSI univoco per i dispositivi NVMe tramite InquiryVPD 83h e nuovi formati ReportPhysicalLUNs in stile CISS per supportare i driver del sistema operativo nella raccolta di queste informazioni.
Aggiunta funzionalità di cablaggio diretto per cavi compatibili con la logica di "rilevamento automatico".
L'API delle metriche "PMS (Performance Monitoring Statistics)" è stata deprecata. Anche diverse metriche relative alle prestazioni nell'API "M&P" sono state deprecate; tuttavia, i contatori relativi agli errori vengono ancora mantenuti.
Gli identificatori PCIe del dispositivo NVMe ora vengono segnalati tramite il comando IdentifyPhysicalDevice. Ciò supporta la segnalazione PLDM come parte dell'aggiunta di identificatori univoci SCSI per i dispositivi NVMe.
Aggiunto il supporto per il firmware per segnalare nuovi formati di comandi di inventario del dispositivo del driver del sistema operativo a supporto del futuro supporto per informazioni univoche sui dispositivi SCSI per i dispositivi NVMe e anche aggiunto
supporto per segnalare un ID SCSI univoco per dispositivi NVMe tramite Inquiry VPD 83h e nuovi formati ReportPhysicalLUNs in stile CISS per supportare i driver del sistema operativo nella raccolta di queste informazioni.
Risolto un problema che impediva il rilevamento di unità aggiunte a caldo con un backplane SGPIO se quel segmento di backplane inizialmente non aveva unità installate all'avvio.
- Causa ultima: La logica che decide di disabilitare i PHY "non utilizzati" ha valutato in modo errato le porte collegate
  un backplane SGPIO come non associato a un backplane. Poiché SGPIO non dispone di un meccanismo fuori banda standardizzato per rilevare l'hotplug, la disabilitazione dei PHY del controller dopo il rilevamento iniziale ha impedito il rilevamento di futuri hotplug.
- Aggiustare: Per un backplane a collegamento diretto, lascia i PHY del controller abilitati per supportare il rilevamento hot plug in banda.
- Rischio: Basso
Risolto un problema per cui la velocità di collegamento segnalata per le unità NVMe viene segnalata in modo errato quando la larghezza della porta desiderata non corrisponde alla larghezza effettiva della porta collegata.
- Causa principale: la segnalazione dal firmware non era sufficientemente granulare per segnalare la disparità. Dopo che il problema è stato risolto, il firmware tenterà di disabilitare i PHY "non utilizzati" dal gruppo di porte, ma ciò causerebbe la disabilitazione dell'intera porta dell'unità.
- Aggiustare: La logica del firmware è stata aggiornata per riportare correttamente lo stato/le velocità del collegamento PHY discreto. Anche la logica del firmware per disabilitare i PHY "non utilizzati" è stata modificata per non disabilitare i PHY per una porta NVMe in cui è collegato almeno un PHY.
- Rischio: Basso
Risolto un problema per cui il WWID del controller viene stampato in modo errato durante l'avvio nel registro UART/SOB.
- Causa ultima: È stata apportata una modifica di refactoring agli output del formato di produzione generale insieme all'aggiunta del supporto per un nuovo formato separato. Questo codice refactoring tratta in modo errato il file

WWID come campo QWORD invece di un array BYTE che fa apparire l'output scambiato endian.

La modifica ha influito solo su questa funzione di stampa: il WWID è stato altrimenti utilizzato correttamente e riportato altrove in modo appropriato.
- Aggiustare: Modificata la logica riportandola alla stampa del valore WWID come matrice BYTE.
- Rischio: Basso
• Risolto un problema per cui le unità collegate a un backplane VPP hanno numeri di alloggiamento errati e vengono presentate all'host in modo errato.
- Causa ultima: La logica di rilevamento VPP ha trovato un dispositivo TWI all'indirizzo 0xAE ma ne ha letto tutti gli 0xFF. Ciò ha comportato un comportamento che ha impostato il contenitore presupponendo una EEPROM errata, ma ciò ha comportato diversi problemi di esperienza del cliente.
- Aggiustare: La logica che segue con una EEPROM difettosa è stata adattata per tenere conto di un target TWI reattivo senza dati validi. Questo caso verrà ora trattato più come un caso cablato direttamente senza custodia.
- Rischio: Basso
Risolto un problema per cui il danneggiamento del flash NOR nella versione del firmware o nella tabella di checksum risultava in un danneggiamento non correggibile.
- Causa ultima: Le informazioni sulla versione del firmware venivano corrette ma non contrassegnate come tali e la tabella del checksum non veniva corretta. In entrambi i casi, il controller continua a segnalare di aver rilevato e non aver riparato il danneggiamento.
- Aggiustare: Entrambi questi casi sono correggibili se l'immagine ridondante è coerente, quindi è stata aggiunta la logica per eseguire la correzione e segnalare correttamente tale stato.
- Rischio: Basso
Risolto un problema per cui il primo avvio a freddo dopo un aggiornamento del firmware segnala un danneggiamento dell'immagine ridondante.
- Causa ultima: I risultati dell'addestramento DDR vengono archiviati in una sezione dell'immagine ridondante in modo da potervi fare riferimento per velocizzare l'addestramento durante l'avvio. All'aggiornamento del firmware, questi risultati vengono cancellati per consentire a potenziali nuovi algoritmi nel nuovo firmware di stabilire risultati nuovi/migliori. Lo stack RAID includeva erroneamente questa sezione nei confronti tra i contenuti dell'immagine attiva e inattiva che attivava un falso messaggio di danneggiamento dell'immagine.
- Aggiustare: Non includere questa sezione nel confronto delle immagini a meno che i risultati memorizzati non siano già coerenti.
- Rischio: Basso
Risolto un potenziale blocco del controller 0x1ABD quando un'unità SATA si guasta con IO in sospeso e l'unità non risponde a Identifica dispositivo dopo il ripristino.
- Causa ultima: Esiste la possibilità nel firmware di accodare un IO a un dispositivo in un momento in cui si verifica un errore e ciò può portare all'irrecuperabilità dell'IO quando l'unità non risponde. Un altro ripristino del dispositivo potrebbe aver ripristinato l'IO, tuttavia la logica di timeout dell'IO del firmware escludeva esplicitamente l'invio della gestione dell'attività di ripristino ai dispositivi già contrassegnati come non riusciti.
- Aggiustare: Nella gestione del timeout, consenti azioni come il ripristino del dispositivo sui dispositivi contrassegnati come non riusciti. Aggiunto anche
  un passaggio di ripristino IO attivo alla routine di errore del dispositivo per interrompere attivamente le richieste in sospeso anziché attendere che il dispositivo (o SATL) elabori normalmente le sue code.
- Rischio: Basso
Risolto un problema per cui il firmware riportava erroneamente "Attivazione firmware online" come set di funzionalità supportate di questo prodotto.
- Causa principale: il firmware pubblicizzava erroneamente la funzionalità di attivazione del firmware online come supportata. Quando il software host osserva questi bit di supporto e tenta di utilizzare la funzione, potrebbe riscontrare errori perché non è effettivamente supportato.
- Aggiustare: Modificati i vari meccanismi di segnalazione delle funzionalità per indicare che questa funzionalità non è supportata.
- Rischio: Basso
Risolto un problema di blocco dell'eccezione TLB quando più richieste MCTP fuori banda venivano inviate contemporaneamente al firmware.
- Causa principale: l'eccezione del puntatore TLB/NULL si verifica nel firmware quando riceve richieste MCTP asincrone contemporaneamente in una sessione in cui una precedente richiesta MCTP non è stata elaborata completamente. A causa di ciò, il firmware entra in una situazione sensibile alla temporizzazione in cui uno dei thread nel firmware sta impostando le risposte MCTP pacchettizzate accedendo al buffer di memoria della sessione OOB che è stato appena liberato da un altro thread responsabile dell'elaborazione delle richieste MCTP. Questo perché il firmware gestisce una richiesta MCTP in una sessione in modo sincrono, se riceve un'altra richiesta dalla stessa sessione prima di completare la richiesta esistente, elimina il vecchio contesto di sessione e avvia l'elaborazione della nuova richiesta.
  - Aggiustare: Per gestire con garbo questa situazione, il firmware utilizzerà lo spinlock durante l'accesso alla sessione OOB da thread diversi.
  - Rischio: Basso
Risolto un problema con prestazioni ridotte quando l'host invia flussi di I/O sequenziali di grandi dimensioni a una profondità di coda elevata.
- Causa principale: quando le richieste vengono unite e stagEd, questa attività si verifica nel contesto di ingresso IO dell'host (PARSE) o nel contesto di mappatura RAID (MAPPER). Quando PARSE sta prendendo decisioni su quando stage dati e staging le risorse sono limitate, stava entrando in un ciclo di attesa occupato per consentire i completamenti per liberare risorse e controllava questo ciclo ogni 10 ms (o 100 IO/s). In questo particolare carico di lavoro, lo stato stazionario del sistema faceva sì che l'ingresso IO fosse completamente controllato su questo ciclo, il che si traduceva in una quantità molto prevedibile e fissa di IO.
- Aggiustare: Il timer del loop di attesa occupato è stato ridotto a 100 µs (o 10k IO/s), che è più che sufficiente per saturare il throughput del controller.
- Rischio: Basso
Correzioni UEFI/Legacy BIOS
Questa sezione mostra le correzioni e i miglioramenti UEFI/Legacy BIOS per questa versione.
Correzioni e miglioramenti per UEFI Build 1.4.3.6/Legacy BIOS Build 1.4.3.2
Questa versione fornisce le seguenti correzioni e miglioramenti.
Aggiunta un'opzione HII nelle impostazioni del protocollo di rilevamento delle porte per supportare le unità collegate via cavo.
Aggiunto il supporto per lo stato del motivo dell'ultimo errore dell'unità nel menu delle informazioni sul disco HII.
Risolto un problema per cui le unità HBA guaste non vengono visualizzate in HII.
- Causa ultima: I dispositivi HBA guasti non vengono visualizzati in HII e nei messaggi di integrità del driver.
- Aggiustare: Popola e fornisci le informazioni disponibili sui dispositivi guasti nei messaggi HII e sullo stato del driver.
- Esposizione: Tutte le versioni precedenti.
- Rischio: Basso
Risolto un problema per cui l'SCT dei test di autocertificazione UEFI non riesce per il protocollo Component name2.
- Causa ultima: GetControllerName del protocollo Component name2 non convalida la lingua di input. SCT ha esito negativo quando viene fornita una lingua errata come input.
- Aggiustare: Convalida della lingua supportata aggiunta per GetControllerName del protocollo Component name2.
- Esposizione: Tutte le versioni precedenti.
- Rischio: Basso
Risolto un problema per cui le modifiche al protocollo di rilevamento delle porte non forniscono lo stato per informare gli utenti che è necessario un riavvio.
- Causa ultima: lo stato operativo del protocollo di rilevamento delle porte mostra solo se è riuscito o meno.
- Aggiustare: Aggiunto messaggio di richiesta di riavvio nello stato finale delle impostazioni del protocollo di rilevamento delle porte.
- Esposizione: Tutte le versioni precedenti.
- Rischio: Basso
Risolto un problema per cui la CLI UEFI ARCCONF produce un errore come comando non riconosciuto nella shell EFI.
- Causa ultima: Intestazione errata per i comandi della pagina delle funzionalità di rilevamento che portano a una convalida errata del bit della funzionalità che considera la funzionalità ARCCONF CLI come non supportata.
- Correzione: correzione delle intestazioni dei comandi della pagina delle funzionalità di rilevamento come da specifica per ottenere bit di funzionalità corretti per la funzionalità CLI ARCCONF.
- Esposizione: Tutte le versioni precedenti.
- Rischio: Basso

Correzioni del driver
Questa sezione mostra le correzioni e i miglioramenti del driver per questa versione.

Correzioni dei driver di Windows
Questa sezione mostra le correzioni e i miglioramenti del driver di Windows per questa versione.

Correzioni e miglioramenti per Windows Driver Build 1010.6.0.1025
Questa versione fornisce le seguenti correzioni e miglioramenti.

Risolto un problema per cui il sistema operativo poteva non avviarsi.
- Causa ultima: Il driver può non riuscire a caricarsi perché la scrittura del registro della funzione di configurazione della coda dell'amministratore e quindi la lettura del registro senza indugio possono dare uno stato erroneamente obsoleto.
- Aggiustare: Aggiunto un ritardo di 1ms=1000us dopo la scrittura del registro della funzione di configurazione della coda dell'amministratore, ma prima che il polling inizi lo stato del polling.
- Rischio: Basso

Correzioni dei driver Linux
Questa sezione mostra le correzioni e i miglioramenti del driver Linux per questa versione.

Correzioni e miglioramenti per Linux Driver Build 2.1.12-055

Risolto un problema per cui venivano creati nodi dispositivo duplicati per l'unità nastro Ultrium e il dispositivo di sostituzione del supporto.
- Causa ultima: L'unità nastro Ultrium è una destinazione SCSI multi-LUN. Presenta un LUN per l'unità a nastro e un secondo LUN per il dispositivo di sostituzione del supporto. Il nostro firmware del controller elenca entrambi i LUN nei risultati RPL. Di conseguenza, il driver smartpqi espone entrambi i dispositivi al sistema operativo. Quindi il sistema operativo esegue la normale individuazione del dispositivo tramite il comando SCSI REPORT LUNS, che fa sì che rilevi entrambi i dispositivi una seconda volta, con il risultato di duplicare i nodi del dispositivo. Questo comportamento non funzionante è stato mascherato da un precedente bug di smartpqi che ha impedito al sistema operativo di rilevare il dispositivo per questo tipo di dispositivo. Questo bug di mascheramento è stato corretto da una recente modifica a smartpqi per riportare informazioni più accurate sui protocolli della porta dell'iniziatore SAS e sui protocolli della porta di destinazione.
- Aggiustare: Quando il sistema operativo rileva nuovamente i due LUN per l'unità nastro e il dispositivo di sostituzione del supporto, il driver riconosce che sono già stati segnalati e impedisce al sistema operativo di aggiungerli una seconda volta.
- Rischio: Basso
Risolto un problema per cui in alcune situazioni, quando il driver porta offline il controller, può verificarsi un arresto anomalo del kernel.
- Causa principale: durante la disattivazione del controller, è possibile che il driver non riesca a completare gli IO che sono già stati completati dal sistema operativo, causando un arresto anomalo del kernel.
- Aggiustare: Se il dispositivo è stato contrassegnato offline dal sistema operativo, non fallire gli IO relativi a quel dispositivo perché gli IO potrebbero essere stati completati in precedenza.
- Rischio: Basso
Risolto un problema con la rimozione del dispositivo tramite sysfs.
- Causa ultima: La definizione di slave_destroy fa sì che SML chiami il nostro slave_destroy per rimuovere il dispositivo dalla tabella SCSI. Il nostro slave_destroy non è completo.
- Aggiustare: Rimuovi slave_destroy.
- Rischio: Basso
Risolto un problema per cui request_irq non riusciva durante l'ibernazione del sistema.
- Causa ultima: Il primo argomento irq in "request_irq" non è corretto.
- Aggiustare: Se la modalità di interruzione è impostata su INTx, utilizzare "irq" del dispositivo PCI come primo parametro per request_irq().
- Rischio: Basso
Risolto un problema per cui durante l'ibernazione del sistema, il driver libera tutti gli irq, disabilita gli interrupt MSIx e richiede l'interrupt INTx legacy. Quando il driver richiama request_irq(), il sistema operativo restituisce EINVAL. Per esample, smartpqi 0000:b3:00.0: irq 191 init non riuscito con errore -22 genirq: Flag non corrispondenti irq 34. 00000080 (SmartPQI) rispetto a 00000000 (i40e-0000:1a:00.0:misc).
- Causa ultima: Il primo argomento irq in request_irq non è corretto
- Aggiustare: : Se la modalità Interrupt è impostata su INTx, utilizzare l'irq del dispositivo PCI come primo parametro per request_irq().
- Rischio: Basso
A causa di un cambiamento nel mid-layer SCSI, alcune distribuzioni Linux potrebbero richiedere molto tempo per essere avviate se il sistema viene riavviato mentre uno o più dischi rigidi vengono disinfettati. Ciò è stato osservato su RHEL 7.9/RHEL8.3 e SLES 15SP2.
- Causa ultima: Durante l'avvio, alcuni sistemi operativi sembrano bloccarsi quando ci sono uno o più dischi in fase di sanitizzazione. In base alla sezione 4 Comandi consentiti durante la sanificazione della specifica SCSI SBC4.11.2, alcuni comandi SCSI sono consentiti, ma non le operazioni di lettura/scrittura. Quando il sistema operativo tenta di leggere la tabella delle partizioni del disco, viene restituito un CHECK CONDITION ASC 0x04 ASCQ 0x1b che fa sì che il sistema operativo ritenti la lettura fino al completamento della disinfezione. Questo può richiedere ore.
- Aggiustare: Aggiungi un'unità di test pronta ai dischi HBA e non presentarli al sistema operativo se viene restituito 0x02/0x04/0x1b (disinfezione in corso).
- Rischio: Basso
Risolto un problema con perdita di richieste, calo delle prestazioni e arresto anomalo del sistema.
- Causa ultima: Il problema si verifica in una configurazione massima in cui viene esercitato un carico di I/O pesante con reimpostazioni LUN occasionali sui dispositivi esposti. Durante l'esito negativo degli IO in coda nel percorso TMF, si è verificata una perdita di richiesta e quindi voci obsolete nel pool di richieste con conteggio dei riferimenti diverso da zero. Nel percorso di arresto, è presente un BUG_ON per rilevare l'I/O bloccato nel firmware o nel driver. La richiesta obsoleta non liberata ha causato un arresto anomalo del sistema. Se la situazione di cui sopra continua a verificarsi, il pool di richieste di I/O continua a perdere e potrebbe verificarsi un calo significativo delle prestazioni.
- Aggiustare: Il driver ora libera correttamente la richiesta trapelata nel percorso TMF mentre non riesce le richieste in sospeso.
- Rischio: Basso
Risolto un problema per evitare errori di I/O per i dispositivi che non sono online.
- Causa ultima: Durante la messa offline del controller, è possibile che il driver non riesca a eseguire IO che sono già stati completati dal sistema operativo, causando un arresto anomalo del kernel.
- Aggiustare: Se il dispositivo è stato contrassegnato offline dal sistema operativo, non fallire gli IO relativi a quel dispositivo poiché gli IO potrebbero essere stati completati in precedenza.
- Rischio: Basso
Correzioni dei driver VMware
Questa sezione mostra le correzioni e i miglioramenti del driver VMware per questa versione.
Correzioni e miglioramenti per VMware Driver Build 4150.0.119
Questa versione fornisce le seguenti correzioni e miglioramenti.
Aggiunto il supporto per i nuovi formati estesi nei dati restituiti dal comando Report Physical LUNs per i controller che supportano questa funzione. I nuovi formati consentono la segnalazione di WWID a 16 byte.
Risolto un problema per cui veniva osservato PSOD durante l'esecuzione dello strumento MBT.
- Causa ultima: Durante attach(), il driver salva il puntatore della struttura privata per ogni adattatore in un array globale. L'indice dell'array non è mai stato decrementato durante lo scaricamento. Ciò ha comportato l'accesso fuori limite dell'array e porta a PSOD.
- Aggiustare: Cancella il puntatore della struttura privata durante driver detach().
- Rischio: Medio
Risolto un problema con l'allineamento degli elementi SG solo per i controller a tre modalità.
- Causa ultima: NVMe richiede un attributo di allineamento a quattro byte nelle impostazioni del motore DMA.
- Aggiustare: Per i controller tri-mode, utilizzare un motore dma personalizzato con set di parametri di allineamento DMA SG a 4 byte.
- Rischio: Medio
Risolto un problema per evitare errori di I/O per i dispositivi che non sono online.
- Causa ultima: Durante la messa offline del controller, è possibile che il driver non riesca a eseguire IO che sono già stati completati dal sistema operativo, causando un arresto anomalo del kernel.
- Aggiustare: Se il dispositivo è stato contrassegnato offline dal sistema operativo, non fallire gli IO relativi a quel dispositivo poiché gli IO potrebbero essere stati completati in precedenza.
- Rischio: Basso
Risolto un problema con un processo di inattività del dispositivo non sicuro.
- Causa ultima: Non veniva chiamata un'API del sistema operativo per la sincronizzazione e lo svuotamento degli interrupt.
- Aggiustare: Aggiungi una chiamata all'API del sistema operativo per eliminare eventuali interruzioni in sospeso.
- Rischio: Basso
Risolto un problema con ESXi PSOD nel gestore Smartpqi TMF.
- Causa ultima: Durante il "ripristino virtuale" TMF, il driver itera attraverso le strutture IO e genera interruzioni per tutti gli IO in sospeso. Durante l'inquadratura di una richiesta di interruzione, il driver utilizza il puntatore della struttura del dispositivo dalla struttura IO. Se l'IO associato alla struttura IO viene completato in parallelo, il puntatore della struttura del dispositivo potrebbe reimpostarsi su NULL, provocando un errore di pagina.
- Aggiustare: Utilizza il puntatore della struttura del dispositivo fornito dal gestore TMF del sistema operativo.
- Rischio: Basso
Risolto un problema con ESXi PSOD a causa di errori di pagina.
- Causa principale: un comando di richiesta a una delle unità sta scadendo e il sistema operativo emette un'interruzione TMF. Durante il completamento del TMF, il driver stamperà lo stato del TMF. Internamente, utilizza la struttura privata del driver che non è stata impostata durante l'inquadratura della richiesta TMF.
- Aggiustare: Imposta il puntatore della struttura privata del driver durante l'inquadratura della richiesta TMF.
- Rischio: Basso
Risolto un problema con ESXi PSOD a causa di Heartbeat NMI.
Causa ultima: Il conducente acquisisce un lucchetto per ottenere uno slot nella coda in entrata. Tutti i core potrebbero finire per utilizzare la stessa coda in entrata se il numero di mondi di completamento SCSI è inferiore al numero di core. Nella maggior parte dei casi, il numero di mondi di completamento SCSI è uguale al numero di socket e la maggior parte dei server ha da 1 a 2 socket. Ciò potrebbe causare la congestione del blocco poiché molti thread tenteranno di acquisire lo stesso blocco. Il conducente utilizza un blocco personalizzato che esegue un'attesa molto intensa se il blocco non è disponibile. Ciò farà sì che il thread di invio IO mantenga il core della CPU e il thread heartbeat ESXi potrebbe non avere la possibilità di essere eseguito per molto tempo. Ciò comporterà l'emissione da parte di ESXi di un NMI e PSOD sul server.
Aggiustare: Usa lo spinlock nel percorso di invio.
Rischio: Alto
Risolto un problema per cui il sistema si blocca durante il caricamento del driver.
- Causa principale: il driver utilizza un timeout infinito per l'invio di comandi interni relativi alla configurazione dell'evento durante l'init del drivertage.
- Correzione: Aggiunto timeout per l'invio di comandi interni relativi alla configurazione degli eventi durante l'inizializzazione del drivertage.
- Rischio: Basso
• Risolto un problema con ESXi 7.0 u2 PSOD durante l'avvio.
- Causa principale: il driver Smartpqi crea un massimo di 64 code in uscita. Le code vengono create in base al numero di mondi di completamento core/scsi e alla disponibilità di MSIX. Al massimo, l'autista creerà 64 code e 64 gestori dovrebbero essere registrati. La dimensione dell'array di dati del gestore del driver era 63 anziché 64 e risultava in PSOD.
- Correzione: corretta la dimensione dell'array di dati del gestore.
- Rischio: Basso
• Risolto un problema per cui i messaggi di interruzione inondavano i registri durante i test di ripristino del dispositivo.
- Causa principale: tutte le richieste di I/O in sospeso a un dispositivo verranno interrotte da una richiesta di reimpostazione del dispositivo in arrivo. Per i dispositivi in grado di eseguire code di profondità elevate, potrebbero trattarsi di decine o centinaia di singole richieste di interruzione per reimpostazione del dispositivo.
- Correzione: modifica del livello di registrazione per questo tipo di messaggio da WARN a INFO, in modo che venga stampato solo quando qualcuno modifica intenzionalmente il livello di registrazione del driver per eseguire il debug o l'analisi.
- Rischio: Basso
Risolto un problema con la registrazione eccessiva durante i ripristini del dispositivo.
- Causa ultima: Durante l'esecuzione dei ripristini, le richieste IO in entrata vengono bloccate e restituite con lo stato DEVICE BUSY. Viene stampato un messaggio per avvisare che il dispositivo è in fase di ripristino.
  Quando si verificano molti ripristini del dispositivo, ad esempio durante i test di certificazione del ripristino, questo genera un volume elevato di attività di registrazione e può causare l'archiviazione frequente dei registri.
- Aggiustare: Modificare questo messaggio in modo che venga registrato solo quando il livello di registrazione viene specificamente modificato in un livello pari o superiore a INFO (0x6). I messaggi sono stati impostati per accedere a o sopra WARN (0x2) e il livello di registrazione del driver è NOTE (0x3) per impostazione predefinita.
- Rischio: Basso
Risolto un problema con PSOD durante lo scaricamento del driver.
- Causa ultima: Il driver Smartpqi mantiene un elenco collegato di dispositivi rimossi a caldo. Ogni volta che è presente un nuovo dispositivo, il driver controlla se quel dispositivo è già presente nell'elenco dei dispositivi_di rimozione e, se è presente, il driver sposta il dispositivo dall'elenco dei dispositivi_di rimozione all'elenco dei dispositivi effettivo. Le voci in remove_device_list saranno reviewed in un intervallo di tempo fisso e l'elenco verrà aggiornato rimuovendo il dispositivo che è stato in tale elenco per più di 20 minuti (per gestire il test hotplug vSAN). Durante lo scaricamento del driver, il driver controlla eventuali dispositivi presenti nell'elenco ed esegue la pulizia (libera la memoria del dispositivo). L'analisi dello stack PSOD indica che la memoria del dispositivo non è stata liberata durante questa pulizia.
- Aggiustare: Rimuove la voce dall'elenco dei dispositivi ogni volta che la memoria del dispositivo viene liberata.
- Rischio: Medio
Risolto un problema per rimuovere i messaggi di stato errati.
- Causa ultima: Il messaggio di stato riporta iu_type invece dello stato.
- Aggiustare: Rimuovi il campo dello stato dai messaggi.
- Rischio: Basso
Corretta l'impostazione della profondità della coda per il dispositivo fisico.
- Causa ultima: Il driver ottiene il valore della profondità della coda dal firmware per ogni destinazione. Se il firmware non fornisce un valore di profondità della coda valido per un target, il driver imposta la profondità della coda su un valore predefinito (1014 per LD, 27 per PD). Ma per tutti i dispositivi fisici, il driver corrente ripristina la profondità della coda alla profondità massima della coda (1014) indipendentemente dal fatto che il firmware fornisca o meno un QD valido.
- Aggiustare: Aggiungi un controllo appropriato durante l'impostazione della profondità della coda del dispositivo.
- Rischio: Basso
Risolto un problema per cui il driver produce troppe registrazioni di debug.
- Causa ultima: Il livello di registrazione predefinito del driver è stato impostato molto alto durante la fase di sviluppo e non è mai stato riadattato per l'uso in produzione.
- Aggiustare: Modificare il livello di registro predefinito al normale livello predefinito, 3. Regolare il livello di registrazione di alcune funzioni secondo necessità.
- Rischio: Basso
Risolto un problema con la registrazione dettagliata dai gestori degli errori.
- Causa ultima: I messaggi di debug utilizzati nelle funzioni di gestione degli errori del driver vengono stampati al livello di registrazione del sistema "normale".
- Aggiustare: Utilizzare il flag del controller aggiunto di recente e l'opzione in fase di compilazione per disattivare la messaggistica indesiderata.
- Rischio: Basso
risolto un problema con PSOD durante la stampa della memoria DMA tag.
- Causa ultima: Usi del conducente tag (una stringa) per identificare la memoria DMA ed è stato mantenuto utilizzando un puntatore a carattere. Questo tag viene assegnato durante l'allocazione della memoria DMA. In alcuni posti, tag è stato definito come array di caratteri locali e il driver stava mantenendo il puntatore a quello. Durante lo scaricamento del driver, quando il driver tenta di stampare il file tag, che ha provocato un errore di pagina come tag la memoria era locale rispetto alla funzione di allocazione.
- Aggiustare: Mantenere tag usando l'array di caratteri invece di mantenere tag indirizzo.
- Rischio: Basso
Correzioni dei driver FreeBSD/Solaris
Questa sezione mostra le correzioni e i miglioramenti del driver FreeBSD/Solaris per questa versione.
Correzioni e miglioramenti per il driver FreeBSD Build 4130.0.1008
Questa versione fornisce le seguenti correzioni e miglioramenti
Risolto un problema quando le unità vengono aggiunte/rimosse/offline, i dispositivi HBA e i controller vengono visualizzati come valore RAID 0 predefinito.
- Causa principale: non viene eseguito il controllo dei dispositivi fisici o dei controller prima di stampare le informazioni sul display.
- Correzione: modificare la messaggistica in modo che venga stampata in modo diverso in base ai dispositivi fisici e ai controller per identificarli di conseguenza.
- Rischio: Basso
Risolto un problema per cui la struttura CCB non inizializzata provoca un comportamento indefinito quando viene condivisa con il livello CAM.
- Causa principale: CCB viene utilizzato senza cancellare i valori dello stack.
- Correzione: cancella CCB prima che venga utilizzato.
- Rischio: Basso
Risolto un problema per cui il driver disabilita le unità se rileva che il controller è offline ma non ci sono informazioni che registrano il codice di blocco del controller quando è offline.
- Causa principale: il driver non visualizza il codice di blocco del controller.
- Correzione: visualizza il codice di blocco nei registri del driver. Inoltre, il gestore del timer è disabilitato quando il controller è offline per evitare un arresto anomalo del sistema in caso di ritardo durante l'eliminazione successiva alla memoria.
- Rischio: Basso

Correzioni e miglioramenti per Solaris Driver Build 4120.0.1005
Questa versione fornisce le seguenti correzioni e miglioramenti.

Risolto un problema quando le unità vengono aggiunte/rimosse/offline, i dispositivi HBA e i controller vengono visualizzati come valore RAID 0 predefinito.
- Causa ultima: Non è necessario controllare i dispositivi fisici o i controller prima di stampare le informazioni sul display.
- Aggiustare: Modificare la messaggistica in modo che venga stampata in modo diverso in base ai dispositivi fisici e ai controller per identificarli di conseguenza.

Correzioni del software di gestione
Questa sezione mostra le correzioni e i miglioramenti del software di gestione per questa versione.

massimoView Correzioni di Storage Manager/ARCCONF
Questa sezione mostra il maxView Correzioni e miglioramenti di Storage Manager/ARCCONF per questa versione.

Correzioni e miglioramenti per maxView Gestore archiviazione/ARCCONF versione 2.0.0 build 24308|
Questa versione fornisce le seguenti correzioni e miglioramenti.

Supporto per aggiungere il buffer del registro eventi del firmware come parte di "Savesupportarchive".
Supporto per il controller per segnalare i dispositivi fisici non riusciti nella configurazione.
Risolto un problema per cui ARCCONF remoto presenta vulnerabilità di sicurezza OpenSSL.
- Causa ultima: ARCCONF remoto utilizza una versione precedente della libreria open source OpenSSL che presentava vulnerabilità di sicurezza.
- Aggiustare: Aggiunte modifiche a Remote ARCCONF aggiungendo l'ultima versione della libreria OpenSSL che aveva risolto le vulnerabilità di sicurezza.
- Rischio: Basso
Risolto un problema per cui maxView non visualizza correttamente la configurazione quando un dispositivo fisico contiene un nome di modello tra virgolette [“].
- Causa ultima: La presenza di virgolette ["] nel nome del modello del dispositivo fisico ha danneggiato il formato JSON della configurazione, rendendo maxView impossibile visualizzarlo correttamente.
- Aggiustare: Aggiunte modifiche alla creazione della configurazione JSON per indirizzare caratteri come [“].
- Rischio: Basso

Limitazioni
Questa sezione mostra le limitazioni per questa versione.

Limitazioni del firmware
Questa sezione mostra le limitazioni del firmware per questa versione.

Limitazioni per la versione del firmware
Non ci sono limitazioni note per questa versione.

Limitazioni del BIOS UEFI/Legacy
Questa sezione mostra le limitazioni UEFI/Legacy BIOS per questa versione.

Limitazioni per UEFI Build 1.4.3.6/Legacy BIOS Build 1.4.3.2
Non ci sono limitazioni note per questa versione.

Limitazioni del conducente
Questa sezione mostra le limitazioni del driver per questa versione.

Limitazioni del driver di Windows
Questa sezione mostra le limitazioni del driver di Windows per questa versione.

Limitazioni per Windows Driver Build 1010.6.0.1025
Non ci sono limitazioni note per questa versione.

Limitazioni del driver Linux
Questa sezione mostra le limitazioni del driver Linux per questa versione.

Limitazioni per Linux Driver Build 2.1.12-055
Questa versione include le seguenti limitazioni.

Sui sistemi AMD/RHEL 7.9, il sistema potrebbe andare in panico a causa di un bug nel modulo IOMMU. Per i dettagli, fare riferimento a https://lore.kernel.org/linux-iommu/20191018093830.GA26328@suse.de/t/
- Soluzione alternativa: Disattivare l'opzione di impostazione IOMMU nel BIOS.
A seconda delle configurazioni hardware, il parametro smartpqi esporre_ld_first potrebbe non funzionare sempre in modo coerente.
- Soluzione alternativa: Nessuno
L'ibernazione del sistema Linux tramite il comando "pm-hibernate" provoca il blocco del sistema.
- Soluzione alternativa: Nessuno

Limitazioni del driver VMware
Questa sezione mostra le limitazioni del driver VMware per questa versione.

Limitazioni per VMware Driver Build 4150.0.119
Non ci sono limitazioni note per questa versione.

Limitazioni del driver FreeBSD/Solaris
Questa sezione mostra le limitazioni del driver FreeBSD/Solaris per questa versione.2.3.3.4.1 Limitazioni per FreeBSD Driver Build 4130.0.1008
Non ci sono limitazioni note per questa versione.

Limitazioni per Solaris Driver Build 4120.0.1005
Non ci sono limitazioni note per questa versione.

Limitazioni del software di gestione

Questa sezione mostra le limitazioni del software di gestione per questa versione.

massimoView Limitazioni di Storage Manager/ARCCONF
Questa sezione mostra il maxView Limitazioni di Storage Manager/ARCCONF per questa versione.

Limitazioni per maxView Gestore archiviazione/ARCCONF versione 2.0.0 build 24308
Non ci sono limitazioni note per questa versione.

Aggiornamento del firmware del controller

Questa sezione descrive come aggiornare il firmware del controller all'ultima versione.
Aggiornamento dei controller all'ultimo firmware
Se il firmware in esecuzione è 3.01.00.006 o precedente, contattare il team Adaptec Apps all'indirizzo ask.adaptec.com.
Aggiornamento al firmware 3.01.04.072

Per i controller che eseguono il firmware 3.01.02.042 o superiore, eseguire il flashing con la versione 3.01.04.072 del firmware "SmartFWx200.bin" fornito in questo pacchetto utilizzando max.view o l'utilità ARCCONF.
Spegnere e riaccendere il server.

Cronologia delle revisioni

Tabella 4-1. Cronologia delle revisioni

Revisione	Data	Descrizione
B	08/2021	Aggiornato per la versione SR 3.1.4.
A	06/2021	Documento creato.

Il microchip Websito

Microchip fornisce supporto online tramite il nostro websito a www.microchip.com/. Questo webil sito è utilizzato per fare filee informazioni facilmente accessibili ai clienti. Alcuni dei contenuti disponibili includono:

Supporto al prodotto – Schede tecniche ed errata, note applicative e sampprogrammi, risorse di progettazione, guide per l'utente e documenti di supporto hardware, ultime versioni software e software archiviato
Supporto tecnico generale: domande frequenti (FAQ), richieste di supporto tecnico, gruppi di discussione online, elenco dei membri del programma dei partner di progettazione Microchip
Business di Microchip - Guide per la selezione e l'ordinazione dei prodotti, gli ultimi comunicati stampa di Microchip, elenco di seminari ed eventi, elenchi di uffici vendita, distributori e rappresentanti di fabbrica Microchip

Servizio di notifica di modifica del prodotto

Il servizio di notifica di modifica del prodotto di Microchip aiuta a mantenere i clienti aggiornati sui prodotti Microchip. Gli abbonati riceveranno una notifica via e-mail ogni volta che ci sono modifiche, aggiornamenti, revisioni o errata relativi a una specifica famiglia di prodotti o strumento di sviluppo di interesse. Per registrarti vai su www.microchip.com/pcn e seguire le istruzioni di registrazione.

Assistenza clienti

Gli utenti dei prodotti Microchip possono ricevere assistenza attraverso diversi canali:

Distributore o rappresentante
Ufficio Commerciale Locale
Ingegnere di soluzioni integrate (ESE)
Supporto tecnico

I clienti devono contattare il loro distributore, rappresentante o ESE per ricevere supporto. Sono disponibili anche uffici vendite locali per aiutare i clienti. Un elenco di uffici vendite e sedi è incluso in questo documento.
Il supporto tecnico è disponibile tramite websito a: www.microchip.com/support

Funzionalità di protezione del codice dei dispositivi a microchip

Nota i seguenti dettagli della funzione di protezione del codice sui dispositivi Microchip:

I prodotti Microchip soddisfano le specifiche contenute nella rispettiva scheda tecnica Microchip.
Microchip ritiene che la sua famiglia di prodotti sia sicura se utilizzata nel modo previsto e in condizioni normali.
Esistono metodi disonesti e forse illegali utilizzati nel tentativo di violare le funzionalità di protezione del codice dei dispositivi Microchip. Riteniamo che questi metodi richiedano l'utilizzo dei prodotti Microchip in modo al di fuori delle specifiche operative contenute nelle Schede tecniche di Microchip. I tentativi di violare queste funzionalità di protezione del codice, molto probabilmente, non possono essere compiuti senza violare i diritti di proprietà intellettuale di Microchip.
Microchip è disposta a lavorare con qualsiasi cliente preoccupato per l'integrità del proprio codice.
Né Microchip né altri produttori di semiconduttori possono garantire la sicurezza del suo codice. La protezione del codice non significa che garantiamo che il prodotto è "indistruttibile". La protezione del codice è in continua evoluzione. Noi di Microchip ci impegniamo a migliorare continuamente le funzionalità di protezione del codice dei nostri prodotti. I tentativi di infrangere la funzione di protezione del codice di Microchip possono costituire una violazione del Digital Millennium Copyright Act. Se tali atti consentono l'accesso non autorizzato al tuo software o altra opera protetta da copyright, potresti avere il diritto di intentare causa ai sensi di tale legge.

Note legali
Le informazioni contenute in questa pubblicazione sono fornite al solo scopo di progettare e utilizzare i prodotti Microchip. Le informazioni relative alle applicazioni del dispositivo e simili sono fornite solo per comodità dell'utente e possono essere sostituite da aggiornamenti. È tua responsabilità assicurarti che la tua domanda soddisfi le tue specifiche.
QUESTE INFORMAZIONI SONO FORNITE DA MICROCHIP “COSÌ COME SONO”. MICROCHIP NON RILASCIA DICHIARAZIONI O GARANZIE DI ALCUN TIPO, ESPRESSE O IMPLICITE, SCRITTE O ORALI, LEGALI
O ALTRO, IN RELAZIONE ALLE INFORMAZIONI COMPRESE, A TITOLO ESEMPLIFICATIVO, QUALSIASI GARANZIA IMPLICITA DI NON VIOLAZIONE, COMMERCIABILITÀ E IDONEITÀ PER UNO SCOPO PARTICOLARE O GARANZIE RELATIVE ALLA SUA CONDIZIONE, QUALITÀ O PRESTAZIONE.
IN NESSUN CASO MICROCHIP SARÀ RESPONSABILE PER QUALSIASI PERDITA, DANNO, COSTO O SPESA INDIRETTI, SPECIALI, PUNITIVI, INCIDENTALI O CONSEQUENZIALI DI QUALSIASI TIPO RELATIVI ALLE INFORMAZIONI O AL SUO UTILIZZO, COMUNQUE CAUSATI, ANCHE SE MICROCHIP È STATA AVVISATA DELLA POSSIBILITÀ O I DANNI SONO PREVEDIBILI. NELLA MISURA MASSIMA CONSENTITA DALLA LEGGE, LA TOTALE RESPONSABILITÀ DI MICROCHIP PER TUTTE LE RIVENDICAZIONI IN QUALSIASI MODO RELATIVE ALLE INFORMAZIONI O AL SUO UTILIZZO NON SUPERERÀ L'IMPORTO DELLE EVENTUALI TARIFFE CHE HAI PAGATO DIRETTAMENTE A MICROCHIP PER LE INFORMAZIONI. L'uso dei dispositivi Microchip in applicazioni di supporto vitale e/o di sicurezza è interamente a rischio dell'acquirente, e l'acquirente accetta di difendere, indennizzare e tenere indenne Microchip da qualsiasi danno, pretesa, azione legale o spesa derivante da tale uso. Nessuna licenza viene concessa, implicitamente o in altro modo, ai sensi dei diritti di proprietà intellettuale di Microchip, salvo diversa indicazione.

Marchi

Il nome e il logo Microchip, il logo Microchip, Adaptec, AnyRate, AVR, logo AVR, AVR Freaks, BesTime, BitCloud, chipKIT, logo chipKIT, CryptoMemory, CryptoRF, dsPIC, FlashFlex, flexPWR, HELDO, IGLOO, JukeBlox, KeeLoq, Kleer , LANCheck, LinkMD, maXStylus, maXTouch, MediaLB, megaAVR, Microsemi, logo Microsemi, MOST, MOST logo, MPLAB, OptoLyzer, PackeTime, PIC, picoPower, PICSTART, logo PIC32, PolarFire, Prochip Designer, QTouch, SAM-BA, SenGenuity , SpyNIC, SST, SST Logo, SuperFlash, Symmetricom, SyncServer, Tachyon, TimeSource, tinyAVR, UNI/O, Vectron e XMEGA sono marchi registrati di Microchip Technology Incorporated negli Stati Uniti e in altri paesi.

AgileSwitch, APT, ClockWorks, The Embedded Control Solutions Company, EtherSynch, FlashTec, Hyper Speed Control, HyperLight Load, IntelliMOS, Libero, motorBench, mTouch, Powermite 3, Precision Edge, ProASIC, ProASIC Plus, logo ProASIC Plus, Quiet-Wire, SmartFusion, SyncWorld, Temux, TimeCesium, TimeHub, TimePictra, TimeProvider, WinPath e ZL sono marchi registrati di Microchip Technology Incorporated negli Stati Uniti

Soppressione della chiave adiacente, AKS, Analog-for-the-Digital Age, Any Capacitor, AnyIn, AnyOut, Augmented Switching, BlueSky, BodyCom, CodeGuard, CryptoAuthentication, CryptoAutomotive, CryptoCompanion, CryptoController, dsPICDEM, dsPICDEM.net, Dynamic Average Matching, DAM , ECAN, Espresso T1S, EtherGREEN, IdealBridge, In-Circuit Serial Programming, ICSP, INICnet, Intelligent Paralleling, Inter-Chip Connectivity, JitterBlocker, maxCrypto, maxView, memBrain, Mindi, MiWi, MPASM, MPF, logo certificato MPLAB, MPLIB, MPLINK, MultiTRAK, NetDetach, Omniscient Code Generation, PICDEM, PICDEM.net, PICkit, PICtail, PowerSmart, PureSilicon, QMatrix, REAL ICE, Ripple Blocker, RTAX , RTG4, SAM-ICE, Serial Quad I/O, simpleMAP, SimpliPHY, SmartBuffer, SMART-IS, storClad, SQI, SuperSwitcher, SuperSwitcher II, Switchtec, SynchroPHY, Total Endurance, TSHARC, USBCheck, VariSense, VectorBlox, VeriPHY, ViewSpan, WiperLock, XpressConnect e ZENA sono marchi registrati di Microchip Technology Incorporated negli Stati Uniti e in altri paesi.
SQTP è un marchio di servizio di Microchip Technology Incorporated negli USA

Il logo Adaptec, Frequency on Demand, Silicon Storage Technology e Symmcom sono marchi registrati di Microchip Technology Inc. in altri paesi.
GestIC è un marchio registrato di Microchip Technology Germany II GmbH & Co. KG, una sussidiaria di Microchip Technology Inc., in altri paesi.

Tutti gli altri marchi qui menzionati sono di proprietà delle rispettive società. © 2021, Microchip Technology Incorporated, Stampato negli Stati Uniti, Tutti i diritti riservati.
ISBN: 978-1-5224-8477-6

Sistema di gestione della qualità

Per informazioni sui sistemi di gestione della qualità di Microchip, visitare www.microchip.com/qualità.

Vendite e assistenza in tutto il mondo

AMERICHE

ASIA/PACIFICO

EUROPA

Sede aziendale

2355 West Chandler Boulevard. Chandler, AZ 85224-6199

Tel: Numero di telefono: 480-792-7200

Fax: Numero di telefono: 480-792-7277

Supporto tecnico: www.microchip.com/support Web Indirizzo: www.microchip.com Atlanta

Duluth, Georgia

Tel: Numero di telefono: 678-957-9614

Fax: Numero di telefono: 678-957-1455

Austin, Texas

Tel: Numero di telefono: 512-257-3370

Boston Westborough, MA Tel: Numero di telefono: 774-760-0087

Fax: Numero di telefono: 774-760-0088

Chicago

Itasca, IL

Tel: Numero di telefono: 630-285-0071

Fax: Numero di telefono: 630-285-0075

Dallas

Addison, TX

Tel: Numero di telefono: 972-818-7423

Fax: Numero di telefono: 972-818-2924

Detroit

Novi, MI

Tel: Numero di telefono: 248-848-4000

Houston, Texas

Tel: Numero di telefono: 281-894-5983

Indianapolis Noblesville, IN Tel: Numero di telefono: 317-773-8323

Fax: Numero di telefono: 317-773-5453

Tel: Numero di telefono: 317-536-2380

Los Angeles Mission Viejo, California Tel: Numero di telefono: 949-462-9523

Fax: Numero di telefono: 949-462-9608

Tel: Numero di telefono: 951-273-7800

Raleigh, Carolina del Nord

Tel: Numero di telefono: 919-844-7510

Nuova York, Stati Uniti

Tel: Numero di telefono: 631-435-6000

San Jose, California

Tel: Numero di telefono: 408-735-9110

Tel: Numero di telefono: 408-436-4270

Canada – Toronto

Tel: Numero di telefono: 905-695-1980

Fax: Numero di telefono: 905-695-2078

Australia – Sidney

Tel: 61-2-9868-6733

Cina – Pechino

Tel: 86-10-8569-7000

Cina – Chengdu

Tel: 86-28-8665-5511

Cina – Chongqing

Tel: 86-23-8980-9588

Cina – Dongguan

Tel: 86-769-8702-9880

Cina – Canton

Tel: 86-20-8755-8029

Cina – Hangzhou

Tel: 86-571-8792-8115

Cina – RAS di Hong Kong

Tel: 852-2943-5100

Cina – Nanchino

Tel: 86-25-8473-2460

Cina – Qingdao

Tel: 86-532-8502-7355

Cina – Shanghai

Tel: 86-21-3326-8000

Cina – Shenyang

Tel: 86-24-2334-2829

Cina – Shenzhen

Tel: 86-755-8864-2200

Cina – Suzhou

Tel: 86-186-6233-1526

Cina – Wuhan

Tel: 86-27-5980-5300

Cina – Xian

Tel: 86-29-8833-7252

Cina – Xiamen

Tel: 86-592-2388138

Cina – Zhuhai

Tel: 86-756-3210040

India – Bangalore

Tel: 91-80-3090-4444

India – Nuova Delhi

Tel: 91-11-4160-8631

India – Puna

Tel: 91-20-4121-0141

Giappone – Osaka

Tel: 81-6-6152-7160

Giappone – Tokyo

Telefono: 81-3-6880-3770

Corea – Daegu

Tel: 82-53-744-4301

Corea – Seul

Tel: 82-2-554-7200

Malesia – Kuala Lumpur

Tel: 60-3-7651-7906

Malesia – Penang

Tel: 60-4-227-8870

Filippine – Manila

Tel: 63-2-634-9065

Singapore

Tel: 65-6334-8870

Taiwan – Hsin Chu

Tel: 886-3-577-8366

Taiwan-Kaohsiung

Tel: 886-7-213-7830

Taiwan-Taipei

Tel: 886-2-2508-8600

Thailandia – Bangkok

Tel: 66-2-694-1351

Vietnam-Ho Chi Minh

Tel: 84-28-5448-2100

Austria – Wels

Tel: 43-7242-2244-39

Fax: 43-7242-2244-393

Danimarca – Copenaghen

Tel: 45-4485-5910

Fax: 45-4485-2829

Finlandia – Espoo

Tel: 358-9-4520-820

Francia – Parigi

Tel: 33-1-69-53-63-20

Fax: 33-1-69-30-90-79

Germania – Garching

Tel: 49-8931-9700

Germania – Haan

Tel: 49-2129-3766400

Germania – Heilbronn

Tel: 49-7131-72400

Germania – Karlsruhe

Tel: 49-721-625370

Germania – Monaco di Baviera

Tel: 49-89-627-144-0

Fax: 49-89-627-144-44

Germania – Rosenheim

Tel: 49-8031-354-560

Israele – Ra'anana

Tel: 972-9-744-7705

Italia – Milano

Tel: 39-0331-742611

Fax: 39-0331-466781

Italia – Padova

Tel: 39-049-7625286

Paesi Bassi – Drunen

Tel: 31-416-690399

Fax: 31-416-690340

Norvegia – Trondheim

Tel: 47-72884388

Polonia – Varsavia

Tel: 48-22-3325737

Romania – Bucarest

Tel: 40-21-407-87-50

Spagna – Madrid

Tel: 34-91-708-08-90

Fax: 34-91-708-08-91

Svezia – Göteborg

Tel: 46-31-704-60-40

Svezia – Stoccolma

Tel: 46-8-5090-4654

Regno Unito – Wokingham

Tel: 44-118-921-5800

Fax: 44-118-921-5820

Documenti / Risorse

MICROCHIP HBA 1200 Note di rilascio software-firmware [pdf] Istruzioni
HBA 1200, Note di rilascio software-firmware, Note di rilascio firmware, Software-firmware, Note di rilascio

Riferimenti

Manuale d'uso

MICROCHIP HBA 1200 Note di rilascio software-firmware