From owner-freebsd-bugs@FreeBSD.ORG Tue May 2 19:00:36 2006 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 90E0116A9CB for ; Tue, 2 May 2006 19:00:36 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id D529543D45 for ; Tue, 2 May 2006 19:00:35 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k42J0Z4G079532 for ; Tue, 2 May 2006 19:00:35 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k42J0Zax079531; Tue, 2 May 2006 19:00:35 GMT (envelope-from gnats) Date: Tue, 2 May 2006 19:00:35 GMT Message-Id: <200605021900.k42J0Zax079531@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: John Baldwin Cc: Subject: Re: kern/91408 : [irq] ata(4) failure: SETFEATURES SET TRANSFER MODE semaphore timeout !! DANGER Will Robinson !! X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John Baldwin List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2006 19:00:38 -0000 The following reply was made to PR kern/91408; it has been noted by GNATS. From: John Baldwin To: Eugene Grosbein Cc: Eugene Grosbein , bug-followup@freebsd.org, lightsquid@logvinov.com Subject: Re: kern/91408 : [irq] ata(4) failure: SETFEATURES SET TRANSFER MODE semaphore timeout !! DANGER Will Robinson !! Date: Tue, 2 May 2006 14:59:16 -0400 On Monday 01 May 2006 23:37, Eugene Grosbein wrote: > John Baldwin wrote: > > Well, all the IRQs are the same and none of the interrupts were changed to > > be edge triggered or anything like that, so it's not a problem with > > interrupt routing. If the interrupt routing were busted, the IRQ numbers > > would be different. All the pci_link devices do is help the OS figure out > > which IRQ number a device uses. If those numbers are all the same, then > > interrupt routing is not the issue. > > And if it's not interrupt routing problem, what else pci_link affects to? That's all pci_link effects. :( One thing you can try is to turn off the code to disable each of the links during boot. Something like this: Index: acpi_pci_link.c =================================================================== RCS file: /usr/cvs/src/sys/dev/acpica/acpi_pci_link.c,v retrieving revision 1.53 diff -u -r1.53 acpi_pci_link.c --- acpi_pci_link.c 6 Jan 2006 16:14:32 -0000 1.53 +++ acpi_pci_link.c 2 May 2006 18:58:47 -0000 @@ -517,6 +517,7 @@ for (i = 0; i < sc->pl_num_links; i++) sc->pl_links[i].l_initial_irq = sc->pl_links[i].l_irq; +#if 0 /* * Try to disable this link. If successful, set the current IRQ to * zero and flags to indicate this link is not routed. If we can't @@ -528,13 +529,16 @@ for (i = 0; i < sc->pl_num_links; i++) sc->pl_links[i].l_irq = PCI_INVALID_IRQ; else +#endif for (i = 0; i < sc->pl_num_links; i++) if (PCI_INTERRUPT_VALID(sc->pl_links[i].l_irq)) sc->pl_links[i].l_routed = TRUE; +#if 0 if (bootverbose) { device_printf(dev, "Links after disable:\n"); acpi_pci_link_dump(sc); } +#endif ACPI_SERIAL_END(pci_link); return (0); fail: -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org