From owner-freebsd-stable@FreeBSD.ORG Tue Aug 30 15:50:38 2011 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 3120B106564A for ; Tue, 30 Aug 2011 15:50:38 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id F20618FC15 for ; Tue, 30 Aug 2011 15:50:37 +0000 (UTC) Received: by iadx2 with SMTP id x2so2286856iad.13 for ; Tue, 30 Aug 2011 08:50:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Wl5WhMwy268LoFyiVNfZmPNRlnuRBvJL2ujvspDW0ao=; b=dL+X65UdwR4IhyfZSgRLCYY53W3JImLd99nw0QGjBsTJTcsi7OMzw8HPKqIJIow6OT BJnlAlURVsneRvlCX+e61R7JzTIt+dv2rpSlzXmU+rbpm/YiSC7zajUlg8obM4xyv9Tn 4dggQExcVsi0OmvEk8D4ydRiDewJGjXhB+hs4= MIME-Version: 1.0 Received: by 10.231.57.10 with SMTP id a10mr13252898ibh.70.1314719436888; Tue, 30 Aug 2011 08:50:36 -0700 (PDT) Received: by 10.231.149.204 with HTTP; Tue, 30 Aug 2011 08:50:36 -0700 (PDT) In-Reply-To: <4E5BF15F.9070601@es.net> References: <4E5BF15F.9070601@es.net> Date: Tue, 30 Aug 2011 08:50:36 -0700 Message-ID: From: Kevin Oberman To: dart@es.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Unable to shutdown 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: Tue, 30 Aug 2011 15:50:38 -0000 On Mon, Aug 29, 2011 at 1:06 PM, Eli Dart wrote: > > > On 8/28/11 1:06 PM, Bengt Ahlgren wrote: >> >> Kevin Oberman =A0writes: >> >>> I've run into an odd problem with dismounting file systems on a >>> Seagate Expansion portable >>> USB drive. Running 8-stable on an amd64 system and with two FAT32 >>> (msdosfs) file systems >>> on the drive. >>> >>> The drive is "green" and spins down when idle. =A0If an attempt is made >>> to shutdown the >>> system while the drive is spun down, the system goes through the usual >>> shutdown including >>> flushing all buffer out to disk, but when the final disk access to >>> mark the file systems as >>> clean, the drive never spins up and the system hangs until it is >>> powered down. I've found no >>> way to avoid this other then to remember to access the disk and cause >>> it to spin up before >>> shutting down. >>> >>> If I attempt to unmount the file systems when the drive is shut down. >>> the same thing >>> happens, but I can recover as the second file system is still mounted >>> and an ls(1) to that file >>> system will cause the disk to spin up and everything is fine. >>> >>> This looks like a bug, but I don't see why the unmounting of an >>> msdosfs system does not >>> spin up the drive. It's clearly hanging on some operation that is not >>> spinning up the drive, >>> but does block. >>> >>> Any ideas what is going on? Possible fix? >> >> Not a solution to your problem, but a data point: >> >> I have a WD Passport 750GB (2.5") drive with an UFS filesystem on it. = =A0I >> don't think I've tried shutdown with the drive mounted, but I've >> experienced no problems after the drive has spun down, including umount. >> There is just a delay while it spins up. =A0This is on 8.2-REL/i386, tha= t >> is, with the new USB stack. > > In my experience, the issues don't show up at lower capacities. =A0I've s= een > problems with 2TB drives, but 1TB and 1.5TB drives seem to work fine. > > Kevin - how big is the disk in question? "Only" 750G. It's just a little portable drive and not even a new one. It was big back when I bought it, but not any more. I think it might be more of an issue with the particular firmware on the drive. Some CAM operation seems to never complet= e when the drive is spun down. Either: 1. The command cannot be completed with until the drive is spun up, but a firmware bug is not triggering a spin-up or: 2. The command does not need the drive spun up, but a bug in the firmware i= s not allowing the completion wen the drive is not spinning. The more I look at this, the more it seems to me that it is an issue with the Seagate drive and not a FreeBSD issue. Probably a bug that is never triggered on Windows, so is largely unnoticed. I suspect Widows probably orders the command is a subtly different order. It is probably an issue that FreeBSD fails to ever timeout when this happens, though. That makes me suspect that the command in question is one that should always return something immediately. I suppose it is also possible that it is some oddity in the USB stack, too, but I still suspect that the root issue is a firmware bug in the drive. --=20 R. Kevin Oberman, Network Engineer - Retired E-mail: kob6558@gmail.com