From owner-freebsd-current@FreeBSD.ORG Sun Apr 18 05:10:55 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 A1B5B16A4CE; Sun, 18 Apr 2004 05:10:55 -0700 (PDT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B1FF43D2F; Sun, 18 Apr 2004 05:10:54 -0700 (PDT) (envelope-from sos@DeepCore.dk) Received: from DeepCore.dk (sos.deepcore.dk [194.192.25.130]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id i3ICAkZd029899; Sun, 18 Apr 2004 14:10:51 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <40827046.5040604@DeepCore.dk> Date: Sun, 18 Apr 2004 14:10:46 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 0.5 (X11/20040329) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cyrille Lefevre References: <20040418031046.GA105@gits.dyndns.org> In-Reply-To: <20040418031046.GA105@gits.dyndns.org> Content-Type: multipart/mixed; boundary="------------020305090703050904090105" X-mail-scanned: by DeepCore Virus & Spam killer v1.4 cc: freebsd current cc: =?ISO-8859-1?Q?S=F8ren?= =?ISO-8859-1?Q?_Schmidt?= Subject: Re: ATA drives no more seen ! 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: Sun, 18 Apr 2004 12:10:55 -0000 This is a multi-part message in MIME format. --------------020305090703050904090105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cyrille Lefevre wrote: > Hi, > > I've updated my cvs tree on April 13, 2004 through cvsup (w/o refuse), > then I build/install a new world and kernel and Oh! surprise, I can't see > my ATA drives anymore. the offending messages are : This is a known problem and is caused by fallout from the latest changes to the PCI system. Warner and I are working on a solution. You can try my take on fixing that (attached patch).. -Søren --------------020305090703050904090105 Content-Type: text/plain; name="diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="diff" Index: ata/ata-pci.c =================================================================== RCS file: /home/ncvs/src/sys/dev/ata/ata-pci.c,v retrieving revision 1.78 diff -u -r1.78 ata-pci.c --- ata/ata-pci.c 13 Apr 2004 09:44:20 -0000 1.78 +++ ata/ata-pci.c 18 Apr 2004 01:37:20 -0000 @@ -260,8 +260,8 @@ case ATA_ALTADDR_RID: if (ATA_MASTERDEV(dev)) { - start = (unit ? ATA_SECONDARY : ATA_PRIMARY) + ATA_ALTOFFSET-2; - count = 4; + start = (unit ? ATA_SECONDARY : ATA_PRIMARY) + ATA_ALTOFFSET; + count = ATA_ALTIOSIZE; end = start + count - 1; } myrid = 0x14 + 8 * unit; @@ -402,7 +402,7 @@ ch->r_io[i].offset = i; } ch->r_io[ATA_ALTSTAT].res = altio; - ch->r_io[ATA_ALTSTAT].offset = 2; + ch->r_io[ATA_ALTSTAT].offset = ATA_MASTERDEV(device_get_parent(dev)) ? 0:2; ch->r_io[ATA_IDX_ADDR].res = io; if (ctlr->r_res1) { Index: pci/pci.c =================================================================== RCS file: /home/ncvs/src/sys/dev/pci/pci.c,v retrieving revision 1.245 diff -u -r1.245 pci.c --- pci/pci.c 16 Apr 2004 15:01:54 -0000 1.245 +++ pci/pci.c 18 Apr 2004 01:15:26 -0000 @@ -824,6 +824,19 @@ */ if (base == 0) return 1; + + /* + * Ignore ATA device entires that are on compatibility addresses. + * Such entries does not contain valid resources as they are at + * fixed positions to be compatible with old ISA requirements. + */ + if ((pci_get_class(dev) == PCIC_STORAGE) && + (pci_get_subclass(dev) == PCIS_STORAGE_IDE) && + (pci_get_progif(dev) & PCIP_STORAGE_IDE_MASTERDEV) && + !(pci_get_progif(dev) & + (PCIP_STORAGE_IDE_MODEPRIM | PCIP_STORAGE_IDE_MODESEC))) + return 1; + start = base; end = base + (1 << ln2size) - 1; count = 1 << ln2size; @@ -1458,12 +1471,8 @@ int mapsize; /* - * Weed out the bogons, and figure out how large the BAR/map - * is. Note: some devices have been found that are '0' after - * a write of 0xffffffff. We view these as 'special' and - * allow drivers to allocate whatever they want with them. So - * far, these BARs have only appeared in certain south bridges - * and ata controllers made by VIA, nVidia and AMD. + * Weed out the bogons, and figure out how large the BAR/map is. + * Note: we must skip these checks on BAR's that are not valid. */ res = NULL; map = pci_read_config(child, *rid, 4); --------------020305090703050904090105--