Date: Mon, 09 Jul 2007 14:39:38 -0700 From: Nate Lawson <nate@root.org> To: John Baldwin <jhb@freebsd.org> Cc: =?windows-1251?Q?=CC=E8=F5=E0=E8=EB_=CA=F3?=, freebsd-acpi@freebsd.org Subject: Re: Asus P5W DH Deluxe APIC/SMP IRQ problem Message-ID: <4692AB1A.2020705@root.org> In-Reply-To: <200707091414.36956.jhb@freebsd.org> References: <1387899022.20070706140143@mixey.spb.ru> <200707091414.36956.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: > On Friday 06 July 2007 06:01:43 am Михаил Кучин wrote: >> Hi people! >> >> Sorry for my bad english. Writing for the first time. I am searching help >> =) >> >> My OS: >> FreeBSD 6.2-RELEASE >> >> Hardware: >> Asus P5W DH Deluxe MB (ICH7 Chipset) >> Intel Core 2 Duo CPU (6700) >> Integrated Netw Card (Marvell Yukon 88E8053 based Ethernet Controller) >> S3 Trio PCI Video Card (very-very old) >> >> Problem: >> 40% of CPU is occupied by interrupts, in some cases (I tried many >> ways of solving), I have "Interrupt storm detected" message. >> >> atapci2 (see vmstat), as I understand, occupies CPU. Here is my RAID1 > controller with >> 400G Samsung Disks and other ICH7 stuff. >> >> I tried to change in BIOS everything, disable everything, re-plug vga >> card, unplug some RAM. BIOS is fresh: a week ago release. Tried 3 >> different versions. > > Try turning off various device drivers (like myk) to see if you can get the > interrupt storm on IRQ 23 to go away. It is likely a bug in interrupt > routing in your BIOS, but you can use a tunable to work around it, you just > need to figure out which _other_ PCI device (not atapci2) is sending its > interrupts to IRQ 23 rather than the IRQ the BIOS told the OS. Actually, are you sure about that? My first guess was that maybe the video card's slot is routed to irq 23. But then, I saw this in the dmesg: > atapci1: <Intel ICH7 UDMA100 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0 > ata0: <ATA channel 0> on atapci1 > ata1: <ATA channel 1> on atapci1 > atapci2: <Intel ICH7 SATA300 controller> port 0xe400-0xe407,0xe080-0xe083,0xe000-0xe007,0xdc00-0xdc03,0xd880-0xd88f mem 0xfebfb800-0xfebfbbff irq 23 at device 31.2 on pci0 > atapci2: AHCI Version 01.10 controller with 4 ports detected > ata5: <ATA channel 0> on atapci2 > ata6: <ATA channel 1> on atapci2 > ata7: <ATA channel 2> on atapci2 > ata8: <ATA channel 3> on atapci2 Two issues: atapci1 has no irq but it's in the same slot as atapci2 (31.1 vs. 31.2). So it looks like this single controller is getting detected as two different devices? Perhaps one is compat mode (udma100) and one is SATA. In this case, it's ATA's fault for not setting this up right. Also, I see that atapci0 is incorrect in ports detected versus reported. It says "2 ports detected" but reports 3 ports (ata2-4). > atapci0: <JMicron JMB363 SATA300 controller> port 0xac00-0xac07,0xa880-0xa883,0xa800-0xa807,0xa480-0xa483,0xa400-0xa40f mem 0xfe8fe000-0xfe8fffff irq 17 at device 0.0 on pci2 > atapci0: AHCI Version 01.00 controller with 2 ports detected > ata2: <ATA channel 0> on atapci0 > ata3: <ATA channel 1> on atapci0 > ata4: <ATA channel 2> on atapci0 So my guess is that one or more of these ATA issues is the cause. -- Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4692AB1A.2020705>