From nobody@FreeBSD.org  Sat Nov 19 21:28:30 2005
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 4DAB616A41F
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 19 Nov 2005 21:28:30 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id CB89E43D46
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 19 Nov 2005 21:28:29 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.13.1/8.13.1) with ESMTP id jAJLST3L048037
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 19 Nov 2005 21:28:29 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.13.1/8.13.1/Submit) id jAJLSTnC048035;
	Sat, 19 Nov 2005 21:28:29 GMT
	(envelope-from nobody)
Message-Id: <200511192128.jAJLSTnC048035@www.freebsd.org>
Date: Sat, 19 Nov 2005 21:28:29 GMT
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: freebsd-gnats-submit@FreeBSD.org
Subject: Spurious atapci1: failed to enable memory mapping! on ICH7
X-Send-Pr-Version: www-2.3

>Number:         89296
>Category:       i386
>Synopsis:       Spurious atapci1: failed to enable memory mapping! on ICH7
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-i386
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Nov 19 21:30:33 GMT 2005
>Closed-Date:    Thu Jan 05 00:55:56 GMT 2006
>Last-Modified:  Thu Jan 05 00:55:56 GMT 2006
>Originator:     Francis Dupont
>Release:        6.0-RELEASE on i386/amd64
>Organization:
GET/ENST Bretagne
>Environment:
FreeBSD diane.ipv6.rennes.enst-bretagne.fr 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Wed Nov  2 19:07:38 UTC 2005     root@rat.samsco.home:/usr/obj/usr/src/sys/GENERIC  amd64
              
>Description:
On a recent Dell Optiplex 620 (i945G, ICH7 PATA+SATA 150) boot gives a spurious error:
atapci1: failed to enable memory mapping!
which seems to have no bad consequence... BTW the atapci1 (SATA part of the ICH7, atapci0 is the PATA)
has no memory map?
Here are the related bootverbose logs:

found-> vendor=0x8086, dev=0x27df, revid=0x01
        bus=0, slot=31, func=1
        class=01-01-8a, hdrtype=0x00, mfdev=0
        cmdreg=0x0005, statreg=0x0288, cachelnsz=0 (dwords)
        lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
        intpin=a, irq=11
        map[20]: type 4, range 32, base 0000ffa0, size  4, enabled
pcib0: matched entry for 0.31.INTA
pcib0: slot 31 INTA hardwired to IRQ 16
found-> vendor=0x8086, dev=0x27c0, revid=0x01
        bus=0, slot=31, func=2
        class=01-01-8f, hdrtype=0x00, mfdev=0
        cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords)
        lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
        intpin=c, irq=5
        powerspec 2  supports D0 D3  current D0
        map[10]: type 4, range 32, base 0000fe00, size  3, enabled
        map[14]: type 4, range 32, base 0000fe10, size  2, enabled
        map[18]: type 4, range 32, base 0000fe20, size  3, enabled
        map[1c]: type 4, range 32, base 0000fe30, size  2, enabled
        map[20]: type 4, range 32, base 0000fea0, size  4, enabled
pcib0: matched entry for 0.31.INTC
pcib0: slot 31 INTC hardwired to IRQ 20

atapci0: <Intel ICH7 UDMA100 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x37
6,0xffa0-0xffaf irq 16 at device 31.1 on pci0
atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xffa0
ata0: <ATA channel 0> on atapci0
atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0
atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6
ata0: reset tp1 mask=03 ostat0=50 ostat1=00
ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb
ata0: stat1=0x00 err=0x00 lsb=0x00 msb=0x00
ata0: reset tp2 stat0=00 stat1=00 devices=0x4<ATAPI_MASTER>
ata0: [MPSAFE]
ata1: <ATA channel 1> on atapci0
atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170
atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376
ata1: reset tp1 mask=00 ostat0=ff ostat1=ff
ata1: [MPSAFE]
atapci1: <Intel ICH7 SATA150 controller> port 0xfe00-0xfe07,0xfe10-0xfe13,0xfe20
-0xfe27,0xfe30-0xfe33,0xfea0-0xfeaf irq 20 at device 31.2 on pci0
atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xfea0
atapci1: [MPSAFE]
atapci1: failed to enable memory mapping!
ata2: <ATA channel 0> on atapci1
atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0xfe00
atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0xfe10
ata2: reset tp1 mask=01 ostat0=80 ostat1=00
ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00
ata2: reset tp2 stat0=50 stat1=00 devices=0x1<ATA_MASTER>
ata2: [MPSAFE]
ata3: <ATA channel 1> on atapci1
atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0xfe20
atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0xfe30
ata3: reset tp1 mask=00 ostat0=ff ostat1=00
ata3: [MPSAFE]

              
>How-To-Repeat:
Boot 6.0-RELEASE on a PC with an ICH7 (I have no different recent PCs). Note ICH6 and 6300ESB boxes
are available in my lab for more testing.              
>Fix:
I don't know what is the problem. I can change the error in a panic in order to get more details
if nobody finds quickly.
BTW some specific code for the ICH6 should be extended to ICH7 (cf reset code in dev/ata/ata-chipset.c)

>Release-Note:
>Audit-Trail:

From: Arthur Hartwig <arthur.hartwig@nokia.com>
To: bug-followup@FreeBSD.org, Francis.Dupont@enst-bretagne.fr
Cc:  
Subject: Re: i386/89296: Spurious atapci1: failed to enable memory mapping!
 on ICH7
Date: Tue, 22 Nov 2005 16:51:40 +1000

 I also saw this on my Gigabyte GA-*i945P-G motherboard which has an ICH7.
 
 The message is printed as a result of a bus_alloc_resource_any() call in 
 ata_intel_chipinit() in ata-chipset.c. The offending call is
 
 /* SATA parts can be either compat or AHCI */
     else {
         /* if we have BAR(5) as a memory resource we should use AHCI mode */
         ctlr->r_type2 = SYS_RES_MEMORY;
         ctlr->r_rid2 =PCIR_BAR(5);
         if ((ctlr->r_res2 = bus_alloc_resource_any(dev, ctlr->r_type2,
                                                    &ctlr->r_rid2, 
 RF_ACTIVE))) {
 
 The bus_alloc_resource_any() call winds up in pci_alloc_resource() in 
 dev/pci/pci.c which sees the RF_ACTIVE flag is set and triies to enable 
 memory space access by calling PCI_ENABLE_IO() to set the appropriate 
 bit in the PCIR_COMMAND  register of the ATA controller. Unfortunately 
 the memory space enable bit in the ICH7 ATA controller on my motherboard 
 is hardwired to 0 unless the SCRAE bit is one. So the ATA driver could 
 be changed to stop this message appearing but I think the logic in 
 pci_alloc_resource() is flawed - it should not be attempting to enable 
 memory or i/o access UNTIL it has successfully allocated the requested 
 resource. Suggested fix:
 
 change pci_alloc_resource() to read as follows:
 struct resource *
 pci_alloc_resource(device_t dev, device_t child, int type, int *rid,
                    u_long start, u_long end, u_long count, u_int flags)
 {
         struct pci_devinfo *dinfo = device_get_ivars(child);
         struct resource_list *rl = &dinfo->resources;
         struct resource_list_entry *rle;
         pcicfgregs *cfg = &dinfo->cfg;
 
         /*
          * Perform lazy resource allocation
          */
         if (device_get_parent(child) == dev) {
                 switch (type) {
                 case SYS_RES_IRQ:
                         /*
                          * If the child device doesn't have an
                          * interrupt routed and is deserving of an
                          * interrupt, try to assign it one.
                          */
                         if (!PCI_INTERRUPT_VALID(cfg->intline) &&
                             (cfg->intpin != 0))
                                 pci_assign_interrupt(dev, child, 0);
                         break;
                 case SYS_RES_IOPORT:
                 case SYS_RES_MEMORY:
                         rle = resource_list_find(rl, type, *rid);
                         if (rle == NULL)
                                 return (pci_alloc_map(dev, child, type, rid,
                                     start, end, count, flags));
                         break;
                 }
                 /*
                  * If we've already allocated the resource, then
                  * return it now.  But first we may need to activate
                  * it, since we don't allocate the resource as active
                  * above.  Normally this would be done down in the
                  * nexus, but since we short-circuit that path we have
                  * to do its job here.  Not sure if we should free the
                  * resource if it fails to activate.
                  */
                 rle = resource_list_find(rl, type, *rid);
                 if (rle != NULL && rle->res != NULL) {
                         if (bootverbose)
                                 device_printf(child,
                             "Reserved %#lx bytes for rid %#x type %d at 
 %#lx\n",
                                     rman_get_size(rle->res), *rid, type,
                                     rman_get_start(rle->res));
                         /*
                          * Enable IO mode only if the matching resource is
                          * successfully activated else the PCI_ENABLE_IO 
 might
                          * fail and report the failre when it doesn't 
 matter.
                          */
                         if (flags & RF_ACTIVE) {
                             if (bus_generic_activate_resource(dev, 
 child, type,
                                  *rid, rle->res) != 0)
                                 return NULL;
                             else
                                 PCI_ENABLE_IO(dev, child, type);
                         }
                         return (rle->res);
                 }
         }
         return (resource_list_alloc(rl, dev, child, type, rid,
             start, end, count, flags));
 }
 
 I built a kernel with this change, booted it and the memory mapping 
 failure message was gone. All devices seemed to work but I was left 
 wondering if the return in the SYS_RES_MEMORY and SYS_RES_IOPORT case 
 also needs a call to bus_generic_activate_resource() and PCI_ENABLE_IO().
 
 
State-Changed-From-To: open->closed 
State-Changed-By: sos 
State-Changed-When: Thu Jan 5 00:52:50 UTC 2006 
State-Changed-Why:  
The logic in ATA has been changed for this together with proper ICH7 support. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=89296 
>Unformatted:
