From owner-freebsd-bugs@FreeBSD.ORG Tue May 2 03:40:19 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 0E5EA16A400 for ; Tue, 2 May 2006 03:40:19 +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 B22A643D45 for ; Tue, 2 May 2006 03:40:18 +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 k423eIgr018055 for ; Tue, 2 May 2006 03:40:18 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k423eIw7018054; Tue, 2 May 2006 03:40:18 GMT (envelope-from gnats) Date: Tue, 2 May 2006 03:40:18 GMT Message-Id: <200605020340.k423eIw7018054@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Eugene Grosbein 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: Eugene Grosbein List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2006 03:40:19 -0000 The following reply was made to PR kern/91408; it has been noted by GNATS. From: Eugene Grosbein To: John Baldwin 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, 02 May 2006 11:37:21 +0800 John Baldwin wrote: > > On Sunday 30 April 2006 04:44, Eugene Grosbein wrote: > > On Sat, Apr 29, 2006 at 10:54:09PM -0400, John Baldwin wrote: > > > > > > With 6.1-RC of today I have the same sympthoms as with 5.4-RELEASE > > > > (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/80815): > > > > > > > > 1) machine suffers from ATA timeouts if ACPI is fully enabled; > > > > 2) debug.acpi.disable="pci_link" in /boot/loader.conf eliminates the > > > > problem. > > > > > > > > So, Soren seems to be right: this is interrupt routing problem > > > > and not ATA problem. > > > > > > > > The question is: should I consider the workaround mentioned above as > > > > solution? What will I miss if I keep debug.acpi.disable="pci_link" forever? > > > > > > I think it's dangerous > > > > What kind of trouble I am "asking for" while using debug.acpi.disable="pci_link"? > > Because ACPI is rather intertwined, so it is expecting to tell the OS how to > route interrupts in a certain way, and if you enable ACPI the BIOS is expecting > you to use it completely. > > > > and that you should just disable ACPI altogether if you wish to do that. > > > > I think I do not wish that :-) > > Do so at your own risk then. > > > This machive has four OS now: FreeBSD 4.11-RELEASE (uses APM to turn power off), > > Windows 98SE and Windows XP SP2 (use ACPI, no problems with it). > > > > Would I be allowed to turn power off with 6.1 without ACPI enabled? > > Would it be possible not only for 'shutdown -p', but for ACPI power button too? > > No, the power button only works with ACPI. shutdown -p can work using apm > as on 4.x. > > > > Can you provide verbose dmesg's for the > > > case with pci_link disabled and the case where it is not disabled? > > > > Here comes dmesg.acpi (ACPI is fully enabled): > > 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. Does it mean that it is safe for this machine to use pci_link really? And if it's not interrupt routing problem, what else pci_link affects to? Eugene Grosbein