From owner-freebsd-stable Fri Apr 5 10:38:54 2002 Delivered-To: freebsd-stable@freebsd.org Received: from freebsd.dk (fw-rl0.freebsd.dk [212.242.86.114]) by hub.freebsd.org (Postfix) with ESMTP id 5D34937B428 for ; Fri, 5 Apr 2002 10:38:06 -0800 (PST) Received: (from sos@localhost) by freebsd.dk (8.11.6/8.11.6) id g35Ic4R81020; Fri, 5 Apr 2002 20:38:04 +0200 (CEST) (envelope-from sos) From: Søren Schmidt Message-Id: <200204051838.g35Ic4R81020@freebsd.dk> Subject: Re: Problems w/ MFCed ata driver In-Reply-To: <20020405181724.GB919@frolic.no-support.loc> To: Bjoern Fischer Date: Fri, 5 Apr 2002 20:38:04 +0200 (CEST) Cc: freebsd-stable@FreeBSD.ORG Reply-To: sos@freebsd.dk X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG It seems Bjoern Fischer wrote: > > wow, about 30 minutes and the bug is fixed. That was fast. ;-) Yeah, and complaints about to fast MFC's is hammering down already :( There is no way to win here any longer.... > > > 1.) FreeBSD constantly crashes, when I try to detach a channel twice: > [...] > > > ata_detach() seems to call bus_release_resource() with > > > (dev=0xc15a8300, type=1, rid=0, r=0x0; the latter one does not seem right) > > > although the channel is already detached and the kernel crashes later in > > > nexus_release_resource(). > > > > Hmm, "dont do that" :) > > Its an artifact of newbus/missing devfs that it doesn't get caught, > > I'll think about how to do this.. > > Maybe by looking at ch->r_io, ch->r_altio and ch->r_irq as you do in > ata_reinit(). Fix committed to -current already, but MFC will have to wait (SIGH)... > > > The process hangs in tsleep() resp. mi_switch() forever. Any further > > > actions on that ata channel may lead to a crash. Everything else keeps > > > running. > > > > Oops, thats a genuine bug alright.. fixed and committed. > > While you're at it, please do the same for the ATAREINIT ioctl, you > sleeplock the channel within the ioctl dispatcher and ata_reinit() may > return without unlocking right at the start. BTW, why do the locking > in the dispatcher (ataioctl()) and the unlocking in ata_reinit()? Because the locking can be done in ata-reinit since its uses in other places as well, there there it should "just do it".... Again fix just committed to -current, but MFC will have to wait (SIGH)... -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message