From owner-freebsd-acpi@FreeBSD.ORG Thu Jan 17 20:41:06 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D0E316A41B for ; Thu, 17 Jan 2008 20:41:06 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 7C73E13C458 for ; Thu, 17 Jan 2008 20:41:06 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8s) with ESMTP id 228869858-1834499 for multiple; Thu, 17 Jan 2008 15:38:58 -0500 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 m0HKegND084274; Thu, 17 Jan 2008 15:40:43 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Nate Lawson Date: Thu, 17 Jan 2008 15:00:27 -0500 User-Agent: KMail/1.9.7 References: <200801161534.31030.jhb@freebsd.org> <478E855A.7000809@root.org> In-Reply-To: <478E855A.7000809@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801171500.28027.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]); Thu, 17 Jan 2008 15:40:43 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/5493/Thu Jan 17 13:09:26 2008 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: ACPI breaks network, old AMD K6, just FYI 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: Thu, 17 Jan 2008 20:41:06 -0000 On Wednesday 16 January 2008 05:29:46 pm Nate Lawson wrote: > John Baldwin wrote: > > On Wednesday 16 January 2008 12:26:52 pm Michael Ross wrote: > >> Am 16.01.2008, 16:54 Uhr, schrieb John Baldwin : > >> > >>>>> Is your network device getting interrupts (vmstat -i)? > >>>>> > >>>> No. > >>> That's your problem then. :) Can you obtain a full dmesg from a verbose > >>> boot > >>> along with your asl and post them somewhere? > >>> > >> http://www.triplefork.net/montana-acpi/dmesg_acpi_enabled > >> http://www.triplefork.net/montana-acpi/montana.asl > >> http://www.triplefork.net/montana-acpi/sysctl_acpi_enabled > >> > >> http://www.triplefork.net/montana-acpi/dmesg_acpi_disabled > > > > Try setting 'debug.acpi.block_bad_io=1' from the loader. > > John is referring to this section of dmesg: > > > pci_link0: Index IRQ Rtd Ref IRQs > > Initial Probe 0 11 N 0 1 3 4 5 6 7 10 11 12 14 15 > > Validation 0 11 N 0 1 3 4 5 6 7 10 11 12 14 15 > > acpi: bad read from port 0x4d1 (8) > > acpi: bad write to port 0x4d1 (8), val 0x2 > > After Disable 0 255 N 0 1 3 4 5 6 7 10 11 12 14 15 > > pci_link1: Index IRQ Rtd Ref IRQs > > Initial Probe 0 9 N 0 1 3 4 5 6 7 10 11 12 14 15 > > Validation 0 9 N 0 1 3 4 5 6 7 10 11 12 14 15 > > acpi: bad read from port 0x4d1 (8) > > acpi: bad write to port 0x4d1 (8), val 0 > > After Disable 0 255 N 0 1 3 4 5 6 7 10 11 12 14 15 > > pci_link2: Index IRQ Rtd Ref IRQs > > Initial Probe 0 255 N 0 1 3 4 5 6 7 10 11 12 14 15 > > Validation 0 255 N 0 1 3 4 5 6 7 10 11 12 14 15 > > After Disable 0 255 N 0 1 3 4 5 6 7 10 11 12 14 15 > > pci_link3: Index IRQ Rtd Ref IRQs > > Initial Probe 0 255 N 0 1 3 4 5 6 7 10 11 12 14 15 > > Validation 0 255 N 0 1 3 4 5 6 7 10 11 12 14 15 > > After Disable 0 255 N 0 1 3 4 5 6 7 10 11 12 14 15 > > Basically, your AML is poking some PIRQ port directly (a no-no) and > making the IRQ invalid. I'mp4/doc glad that we may have found a system that > needs this safety belt since I implemented it a while ago. It's actually frobbing the ELCR in the _DIS method for the links to mark the IRQ as edge triggered. What is odd is that we should actually be ok even if it does that because we program the ELCR ourselves. Hmm, I bet we only write to the ELCR if we think it is changing though. Yes, that's what you are running into. You could also fix it by editing elcr_write_trigger() in src/sys/i386/isa/elcr.c to remove the 'if (new_status == elcr_status) return;' statement. However, the tunable is actually better as the BIOS can't safely frob these bits in the ELCR. It probably breaks ACPI as ACPI needs IRQ 9 level triggered as well, and apparently the _SRS method isn't updating the ELCR either which it would need to do. -- John Baldwin