From owner-freebsd-current@FreeBSD.ORG Wed Apr 21 05:25:51 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 96ACB16A4CE; Wed, 21 Apr 2004 05:25:51 -0700 (PDT) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD67143D5C; Wed, 21 Apr 2004 05:25:50 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])i3LCPe5v015724; Wed, 21 Apr 2004 22:25:40 +1000 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i3LCPcHW024074; Wed, 21 Apr 2004 22:25:39 +1000 Date: Wed, 21 Apr 2004 22:25:38 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Alex Dupre In-Reply-To: <40864BA9.1070302@FreeBSD.org> Message-ID: <20040421221606.Q8585@gamplex.bde.org> References: <1082542568.765.7.camel@localhost> <40864BA9.1070302@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: Failed to detect hard disk on TP X31 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 12:25:51 -0000 On Wed, 21 Apr 2004, Alex Dupre wrote: > Dennis Kristensen wrote: > > > Just a "me too". With latest source from a few hours ago my ATA devices > > are not probed again but my floppy suddenly is. Reverting the recent > > ata-pci.c/pci.c makes them re-appear, but the floppy to disappear. > > Try to revert only pci.c. This makes my system work againg, and floppy too. Here it did the same, except with pci.c not reverted attempting to use DMA failures on ad0 and a panic in the turnstile code soon after. This was primarily because pci.c broke the ata DMA BAR. Without pci.c reverted, I get the following boot messages: %%% atapci0: port 0xf000-0xf00f at device 9.0 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xf000 atapci0: Lazy allocation of 0x8 bytes rid 0x10 type 4 at 0x1f0 atapci0: Lazy allocation of 0x1 bytes rid 0x14 type 4 at 0x3f6 %%% With pci.c unreverted, rid 0x20 is at 0 instead of at 0xf000. This does not work. Bogus allocations for memory-mapped devices fail safer than bogus allocations for i/o-mapped devices because memory accesses to address 0 cause null pointer panics while port accesses to address 0 just access a wrong port. Bruce