lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 7 Jan 2022 11:05:17 +0000 From: <Ajish.Koshy@...rochip.com> To: <john.garry@...wei.com>, <damien.lemoal@...nsource.wdc.com>, <jejb@...ux.ibm.com>, <martin.petersen@...cle.com>, <jinpu.wang@...ud.ionos.com>, <Viswas.G@...rochip.com> CC: <linux-scsi@...r.kernel.org>, <linux-kernel@...r.kernel.org>, <vishakhavc@...gle.com>, <ipylypiv@...gle.com>, <Ruksar.devadi@...rochip.com>, <Vasanthalakshmi.Tharmarajan@...rochip.com> Subject: RE: [PATCH RFT] scsi: pm8001: Fix FW crash for maxcpus=1 Hi John, > On 06/01/2022 13:03, Ajish.Koshy@...rochip.com wrote: > >> only a specific vector and, also, why we check at all in an > >> interrupt handler. > > Here is my initial understanding so far based on the code and data > > sheet > > > > 1. Controller has the capability to communicate to the host about > > fatal error condition via configured interrupt vector MSI/MSI-X. > > 2. This capability is achieved by setting two fields > > a. Enable Controller Fatal error notification > > Dowrd 0x1C, Bit[0]. > > 1 - Enable; 0 - Disable > > Code: pm8001_ha->main_cfg_tbl.pm80xx_tbl. > > fatal_err_interrupt = 0x01; > > b. Fatal Error Interrupt Vector Dword 0x1C, bit[15:8] > > This parameter configures which interrupt vector > > is used to notify the host of the fatal error. > > Code: /* Update Fatal error interrupt vector */ > > pm8001_ha->main_cfg_tbl.pm80xx_tbl. > > fatal_err_interrupt |= > > ((pm8001_ha->max_q_num - 1) << 8); > > > > Probably this will be the reason why we check the vector in > > process_oq() for processing controller fatal error > > > > if (vec == (pm8001_ha->max_q_num - 1)) { > > > > Please do let me know if it helped in clarification. > > > > Sounds reasonable. And we only discover the issue for 8008/8009 now as we > have that (pm8001_ha->max_q_num - 1) vector being used for standard IO. > > So let me know of any other issue, otherwise I'll send a v2 with the coding > style fixup. After going through check_fw_ready(), the change here looks fine. > > Thanks, > John
Powered by blists - more mailing lists