Re: [REGRESSION][BISECTED] 5.15-rc1: Broken AHCI on NVIDIA ION (MCP79)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 06 Oct 2021 12:06:55 +0100,
Rui Salvaterra <rsalvaterra@xxxxxxxxx> wrote:
> 
> Hi, Marc,
> 
> On Wed, 6 Oct 2021 at 12:00, Marc Zyngier <maz@xxxxxxxxxx> wrote:
> >
> > Could you please give more context for this error? I assume that this
> > is some ATA device probing, but this is unclear at best. A full dmesg
> > definitely help.
> 
> I'd love to have it, but I don't have a serial console to get it from.
> I can take a photo, of course, but there's no stack dump.

That wouldn't be very helpful, unfortunately.

> 
> > 'lspci -vvnn' would also be useful to understand what the device wants
> > in terms of PCI configuration.
> 
> Sure thing, here it goes (complete dump):
> 
> 00:0b.0 SATA controller [0106]: NVIDIA Corporation MCP79 AHCI
> Controller [10de:0ab8] (rev b1) (prog-if 01 [AHCI 1.0])
>     Subsystem: ZOTAC International (MCO) Ltd. MCP79 AHCI Controller [19da:a108]
>     Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B- DisINTx+
>     Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
>     Latency: 0 (750ns min, 250ns max)
>     Interrupt: pin A routed to IRQ 30
>     Region 0: I/O ports at d000 [size=8]
>     Region 1: I/O ports at cc00 [size=4]
>     Region 2: I/O ports at c880 [size=8]
>     Region 3: I/O ports at c800 [size=4]
>     Region 4: I/O ports at c480 [size=16]
>     Region 5: Memory at fae76000 (32-bit, non-prefetchable) [size=8K]
>     Capabilities: [44] Power Management version 2
>         Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>         Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>     Capabilities: [8c] SATA HBA v1.0 InCfgSpace
>     Capabilities: [b0] MSI: Enable+ Count=1/8 Maskable- 64bit+
>         Address: 00000000fee02004  Data: 0026
>     Kernel driver in use: ahci

I guess this is the relevant device? It is interesting that it
advertises not supporting interrupt masking... Can you, you, out of
curiosity, give the following hack a go? I would expect things to
behave badly too (and maybe be even worse). But one way or another, it
may give us a hint.

Thanks,

	M.

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 0099a00af361..b3c0b9d07f17 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -205,7 +205,7 @@ static void __pci_msi_mask_desc(struct msi_desc *desc, u32 mask)
 
 	if (desc->msi_attrib.is_msix)
 		pci_msix_mask(desc);
-	else if (desc->msi_attrib.maskbit)
+	else //if (desc->msi_attrib.maskbit)
 		pci_msi_mask(desc, mask);
 }
 
@@ -216,7 +216,7 @@ static void __pci_msi_unmask_desc(struct msi_desc *desc, u32 mask)
 
 	if (desc->msi_attrib.is_msix)
 		pci_msix_unmask(desc);
-	else if (desc->msi_attrib.maskbit)
+	else //if (desc->msi_attrib.maskbit)
 		pci_msi_unmask(desc, mask);
 }
 

-- 
Without deviation from the norm, progress is not possible.



[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux