From owner-freebsd-current@FreeBSD.ORG Sun Jan 16 10:06:57 2005 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 4344816A4CE for ; Sun, 16 Jan 2005 10:06:57 +0000 (GMT) Received: from error404.nls.net (error404.nls.net [216.144.36.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD8C243D2D for ; Sun, 16 Jan 2005 10:06:56 +0000 (GMT) (envelope-from ketrien@error404.nls.net) Received: from error404.nls.net (ketrien@error404.nls.net [216.144.36.24]) by error404.nls.net (8.13.1/8.13.1) with ESMTP id j0GAAceI034983 for ; Sun, 16 Jan 2005 05:10:38 -0500 (EST) (envelope-from ketrien@error404.nls.net) Date: Sun, 16 Jan 2005 05:10:38 -0500 (EST) From: "Ketrien I. Saihr-Kenchedra" X-X-Sender: ketrien@bahre.achedra.org To: current@freebsd.org Message-ID: <20050116044737.B13189@bahre.achedra.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.80/631/Wed Dec 15 09:01:14 2004 clamav-milter version 0.80j on bahre.achedra.org X-Virus-Status: Clean Subject: LOR in Jan16 -CUR, ACPI related possibly 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: Sun, 16 Jan 2005 10:06:57 -0000 Apologies for the lack of debug, but the workspace around here is really a disaster area, and console's acting up. I tried to get a dump, no go even w/call doadump. kgdb's not working again either, go figure. (I have related work that gave occasion to find this LOR.) Sorry for the seeming lack of detail; I really have no way to accurately transcribe this at the moment. It is 100% reproducible at least, but does not panic() the system. It's as simple as kldload if_pcn, kldunload if_pcn, LOR. 1st pcn (Network driver) sys/pci/if_pcn.c:1385 2nd ACPI root bus sys/dev/acpica/acpi.c:1050 witness_checkorder _sx_xlock acpi_release_resource bus_generic_release_resource bus_release_resource pcn_detach device_detach devclass_delete_driver driver_module_handler module_unload linker_file_unload kern_kldunload syscall Xint0x80_syscall Now, on a similar note, I'm currently working on the pcn(4) driver, and encountered a not-dissimilar LOR versus ACPI again, this on load. I was able to debug that one somewhat, but not scribble much down. This LOR does panic() the system. 1st pcn 2nd ACPI root bus pcn_attach device_attach pci_driver_added devclass_add_driver driver_module_handler module_register_init linker_load_module My code uses mdodd@'s changes to probe(), which, contrary to wording, does still lock out of necessity, but has not exhibited LOR before. The flow is unchaged up to the LOR occurance, which appears to occur at ether_ifattach(). I'm still rooting around to see if it _is_ occuring earlier, but it doesn't look like it. This one, I can't reproduce so well, due to a panic in uma that keeps popping up. Afraid I'm a little stuck on this one; I'm still trying to get gdb working without success. Any chance someone could take a look at this? Thanks, as usual. -Ketrien I. Saihr-Kenchedra caps lock is not your friend. In fact, it is your mortal enemy and it made very disparaging remarks about your mother.