From owner-freebsd-current@FreeBSD.ORG Mon Nov 24 16:01:01 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 46DC816A4CE for ; Mon, 24 Nov 2003 16:01:01 -0800 (PST) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 31DE143FF9 for ; Mon, 24 Nov 2003 16:00:58 -0800 (PST) (envelope-from nate@rootlabs.com) Received: (qmail 87980 invoked by uid 1000); 25 Nov 2003 00:00:59 -0000 Date: Mon, 24 Nov 2003 16:00:59 -0800 (PST) From: Nate Lawson To: John Polstra In-Reply-To: Message-ID: <20031124160013.B87605@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: Tue, 25 Nov 2003 00:01:01 -0000 On Mon, 24 Nov 2003, John Polstra wrote: > On 24-Nov-2003 Nate Lawson wrote: > > > > 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. > > As I mentioned a minute ago, the patch didn't help. But I grabbed > another stack trace while I was at it. This one is quite different > from the others. I don't think it's different because of your > patch, though. I saw one like this earlier, but thought it might > have been an anomaly caused by my own mucking around in DDB. > > siointr1(c298d000,0,c06c9b97,6a0,cdb5ec70) at siointr1+0xec > siointr(c298d000,c053a016,c06d88a0,c06e7ae0,4) at siointr+0x35 > intr_execute_handlers(c129f88c,cdb5ec88,cdb5eccc,c065ca43,34) at > intr_execute_handlers+0xc8 > lapic_handle_intr(34) at lapic_handle_intr+0x3a > Xapic_isr1() at Xapic_isr1+0x33 > --- interrupt, eip = 0xc053a4ea, esp = 0xcdb5eccc, ebp = 0xcdb5eccc --- > critical_exit(c070af20,1,c06b8c37,14b,0) at critical_exit+0x2a > _mtx_unlock_spin_flags(c070af20,0,c06b74f7,23a,c294954c) at > _mtx_unlock_spin_flags+0x9d > ithread_loop(c12a6800,cdb5ed48,c06b7365,311,0) at ithread_loop+0x26e > fork_exit(c0520150,c12a6800,cdb5ed48) at fork_exit+0xb4 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xcdb5ed7c, ebp = 0 --- Someone more familiar with ithread_loop should probably answer this. One workaround might be to enable ACPI_NO_SEMAPHORES on your box. -Nate