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-next>] [day] [month] [year] [list]

Message-ID: <920239.46155.qm@web58101.mail.re3.yahoo.com>
Date:	Tue, 31 Jul 2007 18:06:09 -0700 (PDT)
From:	Craig Block <chblock3@...oo.com>
To:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
Cc:	Tejun Heo <htejun@...il.com>, linux-ide@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re:  IRQ Delivery Problem for MCP65  

--- 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.

 - Craig


       
____________________________________________________________________________________
Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online.
http://smallbusiness.yahoo.com/webhosting 
View attachment "dmesg-no_msi" of type "text/plain" (7695 bytes)

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