linux-kernel - Re: IRQ Delivery Problem for MCP65

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 01 Aug 2007 12:50:46 +0900
From:	Tejun Heo <htejun@...il.com>
To:	Craig Block <chblock3@...oo.com>
CC:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
	linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-pci@...ey.karlin.mff.cuni.cz
Subject: Re: IRQ Delivery Problem for MCP65

[cc'ing linux-pci and quoting whole body.]

Any ideas?

Craig Block wrote:
> --- Bartlomiej Zolnierkiewicz <bzolnier@...il.com> wrote:
> 
>>> --- Craig Block <chblock3@...oo.com> wrote:
> 
>>> I'm having trouble getting Linux to see any hard drives on an ASUS M2N-X
>>> motherboard with an MCP65 (nForce 520) chipset.  When the kernel probes the
>>> AHCI controllers, it hangs for a minute or so on each one and returns the
>>> following;
>>>
>>> ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4)
>> I googled for some more info about similar issues and found very similar
>> problem being discussed on Gentoo forum:
>>
>> The important part is here:
>>
>> "when I disabled Message Signaled Interrupts (MSI and MSI-X) under "Bus
>> Options" in the kernel, the problem magically went away (disabling MSI)"
>>
>> which indicates IRQ routing problems (as suspected from dmesg output and also
>> stated by Tejun).  Have you already tried disabling MSI IRQs with "pci=nomsi"
>> (not "nomsi") or even completely disabling CONFIG_PCI_MSI support?
> 
> Thanks a ton, building the kernel with PCI_MSI not set did the trick. 
> Attempting to disable MSI using pci=nomsi at the boot prompt did not eliminate
> the problem.  I had to build the kernel without MSI support.  There's a few
> interesting differences in the dmesg output with "PCI_MSI=y" and PCI_MSI not
> set;
> 
> With PCI_MSI not set;
> 
> ata1: SATA max UDMA/133 cmd 0xf8804100 ctl 0x00000000 bmdma 0x00000000 irq 5
> ata2: SATA max UDMA/133 cmd 0xf8804180 ctl 0x00000000 bmdma 0x00000000 irq 5
> ata3: SATA max UDMA/133 cmd 0xf8804200 ctl 0x00000000 bmdma 0x00000000 irq 5
> ata4: SATA max UDMA/133 cmd 0xf8804280 ctl 0x00000000 bmdma 0x00000000 irq 5
> 
> With PCI_MSI=y;
> 
> ata1: SATA max UDMA/133 cmd 0xf8804100 ctl 0x00000000 bmdma 0x00000000 irq 219
> ata2: SATA max UDMA/133 cmd 0xf8804180 ctl 0x00000000 bmdma 0x00000000 irq 219
> ata3: SATA max UDMA/133 cmd 0xf8804200 ctl 0x00000000 bmdma 0x00000000 irq 219
> ata4: SATA max UDMA/133 cmd 0xf8804280 ctl 0x00000000 bmdma 0x00000000 irq 219
> 
> Also, there's a spurous interrupt message that appears with PCI_MSI=y;
> 
> spurious 8259A interrupt: IRQ7.
> 
> I attached the two dmesg instances for reference.

-- 
tejun

View attachment "dmesg-no_msi" of type "text/plain" (7695 bytes)

View attachment "dmesg-with_msi" of type "text/plain" (7675 bytes)