Date: Mon, 9 Jul 2007 19:21:23 -0400 From: John Baldwin <jhb@freebsd.org> To: Nate Lawson <nate@root.org> Cc: freebsd-acpi@freebsd.org Subject: Re: Asus P5W DH Deluxe APIC/SMP IRQ problem Message-ID: <200707091921.23548.jhb@freebsd.org> In-Reply-To: <4692AB1A.2020705@root.org> References: <1387899022.20070706140143@mixey.spb.ru> <200707091414.36956.jhb@freebsd.org> <4692AB1A.2020705@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 09 July 2007 05:39:38 pm Nate Lawson wrote: > John Baldwin wrote: > > On Friday 06 July 2007 06:01:43 am =CC=E8=F5=E0=E8=EB =CA=F3=F7=E8=ED w= rote: > >> Hi people! > >> > >> Sorry for my bad english. Writing for the first time. I am searching h= elp > >> =3D) > >> > >> 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 Controlle= r) > >> 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 RAID= 1=20 > > 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. > >=20 > > Try turning off various device drivers (like myk) to see if you can get= =20 the=20 > > interrupt storm on IRQ 23 to go away. It is likely a bug in interrupt= =20 > > routing in your BIOS, but you can use a tunable to work around it, you= =20 just=20 > > need to figure out which _other_ PCI device (not atapci2) is sending it= s=20 > > interrupts to IRQ 23 rather than the IRQ the BIOS told the OS. >=20 > Actually, are you sure about that? My first guess was that maybe the > video card's slot is routed to irq 23. >=20 > But then, I saw this in the dmesg: > > atapci1: <Intel ICH7 UDMA100 controller> port=20 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=20 0xe400-0xe407,0xe080-0xe083,0xe000-0xe007,0xdc00-0xdc03,0xd880-0xd88f mem=20 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 >=20 > 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. This is very normal and I see this all the time where the PATA part is a=20 separate PCI function from the SATA part. > Also, I see that atapci0 is incorrect in ports detected versus reported. > It says "2 ports detected" but reports 3 ports (ata2-4). This is likely harmless as well. > > atapci0: <JMicron JMB363 SATA300 controller> port=20 0xac00-0xac07,0xa880-0xa883,0xa800-0xa807,0xa480-0xa483,0xa400-0xa40f mem=20 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 >=20 > So my guess is that one or more of these ATA issues is the cause. Probably not. His issue is that some device that _isn't_ on IRQ 23 in the= =20 _PRT tables, actually _is_ on IRQ 23. The key is to find out what device=20 (not atapci2) is generating those interrupts. Turning each device off=20 individually to test can figure this out. =2D-=20 John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200707091921.23548.jhb>