From owner-freebsd-bugs@FreeBSD.ORG Fri Nov 15 10:30:02 2013 Return-Path: Delivered-To: freebsd-bugs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 683025BE for ; Fri, 15 Nov 2013 10:30:02 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3E9C32EB7 for ; Fri, 15 Nov 2013 10:30:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rAFAU18X023745 for ; Fri, 15 Nov 2013 10:30:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rAFAU1CU023744; Fri, 15 Nov 2013 10:30:01 GMT (envelope-from gnats) Date: Fri, 15 Nov 2013 10:30:01 GMT Message-Id: <201311151030.rAFAU1CU023744@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Marie Subject: Re: misc/183980: Unreliable hotplug support with Intel Patsburg AHCI SATA controller X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list Reply-To: Marie List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 10:30:02 -0000 The following reply was made to PR misc/183980; it has been noted by GNATS. From: Marie To: FreeBSD-gnats-submit@freebsd.org, freebsd-bugs@freebsd.org Cc: Subject: Re: misc/183980: Unreliable hotplug support with Intel Patsburg AHCI SATA controller Date: Fri, 15 Nov 2013 11:25:41 +0100 --001a11331e46cbbc9004eb349edd Content-Type: text/plain; charset=ISO-8859-1 Following suggestions from mav@ on the FreeBSD forums ( http://forums.freebsd.org/showthread.php?t=43238), I've discovered that the problem was somehow caused by SWAP being enabled on the device which was being unplugged. Considering that 'top' output indicated no swap was being used, and that the system had nearly 63 GB unused memory at the time, I would be surprised if anything was swapped. Although the issue is not what I initially thought it was, I still believe this is a problem which needs resolving, as a hdd dying for whatever reason should not make a port unavailable for what seems like an arbitary period of time. (I have not yet managed to make the port work again by any other way than a reboot, but I only left the system running for up to 15 minutes) --001a11331e46cbbc9004eb349edd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Following suggestions from mav@ on the FreeBSD forums (http://forums.f= reebsd.org/showthread.php?t=3D43238), I've discovered that the prob= lem was somehow caused by SWAP being enabled on the device which was being = unplugged. Considering that 'top' output indicated no swap was bein= g used, and that the system had nearly 63 GB unused memory at the time, I w= ould be surprised if anything was swapped.

Although the issue is not what I initially thought it was, I= still believe this is a problem which needs resolving, as a hdd dying for = whatever reason should not make a port unavailable for what seems like an a= rbitary period of time. (I have not yet managed to make the port work again= by any other way than a reboot, but I only left the system running for up = to 15 minutes)
--001a11331e46cbbc9004eb349edd--