From owner-freebsd-acpi@FreeBSD.ORG Mon Jul 9 23:44:12 2007 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 82C4316A400 for ; Mon, 9 Jul 2007 23:44:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 13B7C13C459 for ; Mon, 9 Jul 2007 23:44:11 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l69Ni5Ye065211; Mon, 9 Jul 2007 19:44:06 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Nate Lawson Date: Mon, 9 Jul 2007 19:21:23 -0400 User-Agent: KMail/1.9.6 References: <1387899022.20070706140143@mixey.spb.ru> <200707091414.36956.jhb@freebsd.org> <4692AB1A.2020705@root.org> In-Reply-To: <4692AB1A.2020705@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200707091921.23548.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 09 Jul 2007 19:44:08 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3619/Mon Jul 9 18:21:25 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-acpi@freebsd.org Subject: Re: Asus P5W DH Deluxe APIC/SMP IRQ problem X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2007 23:44:12 -0000 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: port=20 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0 > > ata0: on atapci1 > > ata1: on atapci1 > > atapci2: 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: on atapci2 > > ata6: on atapci2 > > ata7: on atapci2 > > ata8: 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: 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: on atapci0 > > ata3: on atapci0 > > ata4: 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