From owner-freebsd-current@FreeBSD.ORG Mon Nov 24 14:02:03 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 934E316A4CE for ; Mon, 24 Nov 2003 14:02:03 -0800 (PST) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 45FE643F75 for ; Mon, 24 Nov 2003 14:02:00 -0800 (PST) (envelope-from nate@rootlabs.com) Received: (qmail 87752 invoked by uid 1000); 24 Nov 2003 22:02:01 -0000 Date: Mon, 24 Nov 2003 14:02:01 -0800 (PST) From: Nate Lawson To: John Polstra In-Reply-To: Message-ID: <20031124135124.G87605@root.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: PII SMP system hangs during boot with ACPI enabled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2003 22:02:03 -0000 On Mon, 24 Nov 2003, John Polstra wrote: > On 24-Nov-2003 Nate Lawson wrote: > > > > Please also send the output of acpidump -t -d > jdp-P2.asl > > When I try to run that command, I get: > > acpidump: sysctl machdep.acpi_root does not point to RSDP > > The sysctl command shows that machdep.acpi_root is 0. > Remember, though, in order to boot it I had to disable ACPI in > /boot/loader.conf. Yes, I see. You could use an older kernel like the 5.1R cd. > > If you can break to the debugger after it has hung, a tr would be nice. > > The fact that it didn't occur to me to try that says a lot about how > long I've been away from -current. :-( I've attached traces from > two different boots. They seem to vary somewhat. I can supply line > numbers on request. Trace 1: wakeup(c2944100,0,c06a7546,140,6c) at wakeup+0x4 AcpiOsSignalSemaphore(c2944100,1) at AcpiOsSignalSemaphore+0xa8 AcpiUtReleaseMutex(9,30,c295e8c0,c295e760,cdb64acc) at AcpiUtReleaseMutex+0x8c AcpiUtReleaseToCache(3,c295e760,cdb64ad8,c045ac17,c295e760) at AcpiUtReleaseToCache+0x8c Trace 2: _mtx_unlock_flags(c2944100,0,c06a7546,150,6c) at _mtx_unlock_flags+0x96 AcpiOsSignalSemaphore(c2944100,1) at AcpiOsSignalSemaphore+0xc8 AcpiUtReleaseMutex(9,8,c045f9cc,c2965940,c12a0c00) at AcpiUtReleaseMutex+0x8c AcpiUtAcquireFromCache(2,cdb64bf4,c0462229,c12a0c00,cdb64c34) at AcpiUtAcquireFromCache+0x53 Both of these show that acpi_task_thread is calling a task and then AcpiOsSignalSemaphore is hanging. I'm wondering if your system can't handle the acpi interrupt being moved to irq 20. Please try this (untested) patch that should disable moving the SCI to irq 20. jhb can probably address this better than I. -Nate Index: /sys/i386/acpica/madt.c =================================================================== RCS file: /home/ncvs/src/sys/i386/acpica/madt.c,v retrieving revision 1.7 diff -u -r1.7 madt.c --- /sys/i386/acpica/madt.c 14 Nov 2003 22:26:29 -0000 1.7 +++ /sys/i386/acpica/madt.c 24 Nov 2003 21:51:02 -0000 @@ -538,11 +538,13 @@ } if (intr->Source != intr->GlobalSystemInterrupt) { +#if 0 /* XXX: This assumes that the SCI uses IRQ 9. */ if (intr->GlobalSystemInterrupt > 15 && intr->Source == 9) acpi_OverrideInterruptLevel( intr->GlobalSystemInterrupt); else +#endif ioapic_remap_vector(new_ioapic, new_pin, intr->Source); if (madt_find_interrupt(intr->Source, &old_ioapic, &old_pin) != 0)