From owner-freebsd-stable@FreeBSD.ORG Thu Jun 14 22:28:59 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (unknown [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06DE31065678 for ; Thu, 14 Jun 2012 22:28:59 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 88DC28FC16 for ; Thu, 14 Jun 2012 22:28:58 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id q5EMSpVV072425; Fri, 15 Jun 2012 00:28:51 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q5EMSpjb072424; Fri, 15 Jun 2012 00:28:51 +0200 (CEST) (envelope-from marius) Date: Fri, 15 Jun 2012 00:28:51 +0200 From: Marius Strobl To: Kevin Oberman Message-ID: <20120614222851.GQ46065@alchemy.franken.de> References: <1338419624.36051.94.camel@revolution.hippie.lan> <20120531110215.GA78200@alchemy.franken.de> <20120609121326.GP90133@alchemy.franken.de> <20120609222957.GS90133@alchemy.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: "freebsd-stable@freebsd.org Stable" Subject: Re: Boot hangs on v9 system at CD device probe 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: Thu, 14 Jun 2012 22:28:59 -0000 On Tue, Jun 12, 2012 at 03:17:47PM -0700, Kevin Oberman wrote: > On Sat, Jun 9, 2012 at 3:29 PM, Marius Strobl wrote: > > On Sat, Jun 09, 2012 at 02:38:53PM -0700, Kevin Oberman wrote: > >> On Sat, Jun 9, 2012 at 5:13 AM, Marius Strobl wrote: > >> > On Fri, Jun 08, 2012 at 10:11:48PM -0700, Kevin Oberman wrote: > >> >> On Thu, May 31, 2012 at 9:10 AM, Kevin Oberman wrote: > >> >> I just did the obvious as suggested and built a kernel without ATA_CAM > >> >> and with atapicam. It boots fine and I have my CD/DVD working on 9.0. > >> >> Clearly, there is some issue with ATAPI drives with ATA_CAM as others > >> >> have seen the same thing. It is entirely possible that a serial > >> >> connected drives don't have this issue. It does look like there is > >> >> some locking issue between CAM and GEOM under some circumstances. I > >> >> worry that 10 will lose support for other than ATA_CAM and that the > >> >> work-around will no longer be available. Of course, if ahci fixes it, > >> >> the problem will go away on systems that support it. > >> >> > >> >> Next time I get to the system I will try putting ATA_CAM back and > >> >> adding ahci and report on the results. > >> >> > >> > > >> > I don't think that the latter test makes much sense as the above > >> > mentioned controller doesn't support AHCI. If you could test > >> > whether the following patch works around the issue when using > >> > ATA_CAM that would be more useful. > >> > http://people.freebsd.org/~marius/ata_ite_ATA_CAM_ATA_NO_ATAPI_DMA.diff > >> > >> Will do. It will be a couple of days, though, as I am currently in the > >> process of updating the 1000 ports installed on that system for the > >> major version update. When that is complete, I'll try to get to the > >> location of the system and see if it does the job. Mondy has several > >> meetings, so it will probably be at least Tuesday. > > > > No hurry ... > > I installed the patch and it worked. 9.0-Stable system with ATA_CAM > and cdrom now boot correctly. > > Thanks! > > Will this be committed to head and MFCed soon? I've committed it to head in r237107 as a band-aid for now as it's a sufficiently severe problem. Obviously, fixing ATA_CAM to not break ATAPI CAM instead is the right thing to do. I've already spent quite some time trying to find the underlying but didn't get anywhere with that so far though (granted, most of that wasted time was because of me thinking that this would be due to an endian bug only seen on big endian machines, which turned out to not be the case). AFAICT, mav@ also has ALI hardware affected by this issue, maybe he'll have a look at it eventually ... Marius