From owner-freebsd-current@FreeBSD.ORG Fri Sep 10 10:22:13 2004 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 B1D2816A4CE for ; Fri, 10 Sep 2004 10:22:13 +0000 (GMT) Received: from artax.karlin.mff.cuni.cz (artax.karlin.mff.cuni.cz [195.113.31.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4604143D1D for ; Fri, 10 Sep 2004 10:22:13 +0000 (GMT) (envelope-from cernm0bm@artax.karlin.mff.cuni.cz) Received: by artax.karlin.mff.cuni.cz (Postfix, from userid 10663) id 712EA57F7; Fri, 10 Sep 2004 12:22:11 +0200 (CEST) Date: Fri, 10 Sep 2004 12:22:11 +0200 From: Marian Cerny To: "Bjoern A. Zeeb" Message-ID: <20040910102211.GA15808@artax.karlin.mff.cuni.cz> References: <20040907163133.GA24426@artax.karlin.mff.cuni.cz> <20040908133452.GA11639@artax.karlin.mff.cuni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i cc: freebsd-current@freebsd.org Subject: LOR (re0 and user map) + PANIC 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: Fri, 10 Sep 2004 10:22:13 -0000 Heh, I noticed one more LOR. This one happens when I turn the laptop off using 'halt -p' after syncing disks. It's *hand*-rewritten, because the laptop turned itself off after 10 seconds, despite the fact, that I was inside kernel debugger (I took a shot with my digital photo camera). lock order reversal 1st 0xc177b6e8 re0 (network driver) @ /usr/src/sys/dev/re/if_re.c:1752 2nd 0xc08adee4 user map (user map) @ /usr/src/sys/vm/vm_map.c:2997 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c08bde68,c08beb88,c084ddac) at kdb_backtrace+0x29 withness_checkorder(c08adee4,9,c0808137,bb5) at witness_checkorder+0x544 _sx_xlock(c08adee4,c0808137,bb5) at _sx_xlock+0x50 _vm_map_lock_read(c08adea0,c0808137,bb5,20000004,c16bae6c) at _vm_map_lock_read+0x37 vm_map_lookup(ceef9bb8,0,2,ceef9bbc,ceef9bac) at vm_map_lookup+0x28 vm_fault(c08adea0,0,2,8,c16b5b00) at vm_fault+0x66 trap_pfault(ceef9c80,0,c) at trap_pgault+0xf2 trap(18,10,10,0,3b) at trap+0x335 calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc0575b76, esp = 0xceef9cc0, ebp = 0xceef9cdc --- re_rxeof(c177b000) at re_rxeof+0x2ae re_intr(c177b000) at re_intr+0xb3 ithread_loop(c16bf400,ceef9d48,c16bf400,c05ed66c,0) at ithread_loop+0x124 fork_exit(c05ed66c,c16bf400,ceef9d48) at fork_exit+0xa4 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = exceef9d7c, ebp = 0 --- Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xc fault code = supervisor write, page not present instruction pointer = 0x8:0xc0575b76 stack pointer = 0x10:0xceef8cc0 frame pointer = 0x10:0xceef9cdc code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 22 (irq11: re0 ohci0+) [thread 100019] Stopped at re_rxeof+0x2ae: movl %eax,0xc(%edi) db> This LOR might be obsolete, because I'm not using patched version of if_re0.c for the LOR #26 in LORs database (I'm using 5.3-BETA3). After 5.3-BETA4 will be available, I can send, wether this patch helped in this situation also, because I get this LOR + PANIC in 30% of shutdown attempts. Marian Cerny -- Marian Cerny Jabber: jojo@njs.netlab.cz [ UNIX is user friendly. It's just selective about who its friends are. ]