From owner-freebsd-stable@FreeBSD.ORG Fri Jun 8 09:39:43 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB6CD106566C for ; Fri, 8 Jun 2012 09:39:42 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 657D88FC15 for ; Fri, 8 Jun 2012 09:39:42 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id q589dPdS004399; Fri, 8 Jun 2012 11:39:41 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id q589dPoT004398; Fri, 8 Jun 2012 11:39:25 +0200 (CEST) (envelope-from olli) Date: Fri, 8 Jun 2012 11:39:25 +0200 (CEST) Message-Id: <201206080939.q589dPoT004398@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, pluknet@gmail.com In-Reply-To: X-Newsgroups: list.freebsd-stable User-Agent: tin/1.9.6-20101126 ("Burnside") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.9 (lurza.secnetix.de [127.0.0.1]); Fri, 08 Jun 2012 11:39:41 +0200 (CEST) Cc: Subject: Re: 9-stabe: cd device gone, ATA_CAM panics X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 09:39:43 -0000 Sergey Kandaurov wrote: > This is a wild guess, but see below. > [...] > Probably the way to fix this is to modify > cam_periph_release_locked_buses() to test CAM_PERIPH_INVALID either. > > how about this patch? > (beware: it was not compile tested, just speculating) Thanks for your detailed analysis! I'm afraid the patch is not correct. With that patch, the following page fault occurs (same output as before until "removing device entry"): (cd0:ata2:0:0:0): removing device entry (cd0:nobus:X:X): removing device entry Fatal trap 12: page fault while in kernel mode cpuid = 4; apic id = 04 fault virtual address = 0x20 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff807a0d03 stack pointer = 0x28:0xffffff80002a9270 frame pointer = 0x28:0xffffff80002a9290 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (g_event) trap number = 12 panic: page fault cpuid = 4 KDB: stack backtrace: #0 0xffffffff807a3ca6 at kdb_backtrace+0x66 #1 0xffffffff8076d75e at panic+0x1ce #2 0xffffffff809b7400 at trap_fatal+0x290 #3 0xffffffff809b773d at trap_pfault+0x1ed #4 0xffffffff809b7d5e at trap+0x3ce #5 0xffffffff809a282f at calltrap+0x8 #6 0xffffffff806d6a16 at disk_destroy+0x26 #7 0xffffffff802ba687 at cdcleanup+0x97 #8 0xffffffff802a1e79 at camperiphfree+0x99 #9 0xffffffff802a203e at cam_periph_release_locked+0x1e #10 0xffffffff802a2f62 at cam_periph_release+0x52 #11 0xffffffff802babdd at cdclose+0xbd #12 0xffffffff806d7342 at g_disk_access+0x242 #13 0xffffffff806db628 at g_access+0x188 #14 0xffffffff806fc353 at g_raid_md_taste_ddf+0x1f3 #15 0xffffffff806e96e6 at g_raid_taste+0x126 #16 0xffffffff806db0dd at g_new_provider_event+0x6d #17 0xffffffff806d8c18 at g_run_events+0x1e8 Uptime: 48s Automatic reboot in 15 seconds - press any key on the console to abort By the way, there is a long delay (~20s) before the two "ata2: reset tp1" lines. I guess something hangs here and causes a time-out. I didn't have such delays with 8.x. I need a working DVD drive, so I'm now considering to downgrade to 8-stable. But then again, TMPFS didn't work a well for me as it does in 9-stable (which was the main reason for me to upgrade), so I'm kind of stuck in a difficult situation. I'm willing to test more patches, of course. :-) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd > Can the denizens of this group enlighten me about what the > advantages of Python are, versus Perl ? "python" is more likely to pass unharmed through your spelling checker than "perl". -- An unknown poster and Fredrik Lundh