From owner-freebsd-stable@FreeBSD.ORG Fri Jun 15 09:17:55 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C157F1065670 for ; Fri, 15 Jun 2012 09:17:55 +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 569768FC0A for ; Fri, 15 Jun 2012 09:17:55 +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 q5F9Hrf4075209; Fri, 15 Jun 2012 11:17:53 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id q5F9HrRn075208; Fri, 15 Jun 2012 11:17:53 +0200 (CEST) (envelope-from marius) Date: Fri, 15 Jun 2012 11:17:53 +0200 From: Marius Strobl To: Oliver Fromme Message-ID: <20120615091753.GR46065@alchemy.franken.de> References: <20120614222851.GQ46065@alchemy.franken.de> <201206150716.q5F7GGCD053882@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201206150716.q5F7GGCD053882@lurza.secnetix.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@FreeBSD.ORG 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: Fri, 15 Jun 2012 09:17:55 -0000 On Fri, Jun 15, 2012 at 09:16:16AM +0200, Oliver Fromme wrote: > Marius Strobl wrote: > > [...] > > > > > > http://people.freebsd.org/~marius/ata_ite_ATA_CAM_ATA_NO_ATAPI_DMA.diff > > [...] > > > > 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 ... > > I'm not sure if it's the same or a different issue, but ATA_CAM > also breaks for me with a legacy P-ATA controller (UDMA-133) on > RELENG_9. Removing ATA_CAM and adding "atapicam" fixes it. > > I've described the problem in more detail here: > http://lists.freebsd.org/pipermail/freebsd-stable/2012-June/068175.html > > This is the controller in question: > > pciconf: > atapci0@pci0:3:6:0: class=0x018085 card=0x4d68105a chip=0x4d69105a rev=0x02 hdr=0x00 > vendor = 'Promise Technology, Inc.' > device = '20269' > class = mass storage > > dmesg: > atapci0: port 0xdc00-0xdc07, > 0xd880-0xd883,0xd800-0xd807,0xcc00-0xcc03,0xc880-0xc88f mem > 0xfeaf8000-0xfeafbfff irq 21 at device 6.0 on pci3 This likely is a different issue as atapromise(4) already disables ATAPI DMA by default since before ATA_CAM hit the tree. > > Shall I open a PR with this? > It probably won't hurt to file one and assign it to mav@. Marius